|
|
Posted by Ed Murphy on 11/24/07 02:24
steve wrote:
> Exactly. Think of sql strings. This table, TABLE(TABLE (M VARCHAR(15),
> N VARCHAR(15)),
> is a differnt type than TABLE (N VARCHAR(16), N VARCHAR(16))! This
> means that we couldn't compare the two and undermines real relational
> division. To declare how many characters in a string is clearly the
> opposite of what the relational idea of data independence is all
> about. Relationally there can only be a 'string' type having
> absolutely nothing to do with its storage characteristics. And this
> is the same idea in any programming language. This is just one
> manifestation of how sqls design ignores the concept of a strong type.
Shouldn't you be complaining that such variables are /too/ strongly
typed? Anyway, this is a separate complaint from your previous ones
(at least those that I've seen), and IMO a minor one.
>> This would allow bad developers to commit the common 'a,b,c' 1NF
>> violation in a whole new way, but then bad developers can screw
>> things up in any language.
>
> The view that strings like 'a,b,c' violate the idea of the atomicity
> of a column in an sql table is a direct result of sql's lack of types
> and lack of relationships between types. There is no violation of any
> kind in a relational system because the string can be stored as
> a single value of a column retaining the concept that there individual
> elements involved. It would simply be stored as a 'list' type.
Beyond your simple examples (which I snipped for brevity), a slightly
more interesting usage would be
select x, y -- y's type is e.g. TABLE (Z VARCHAR(15))
from the_table
where 'a' in y
or perhaps this would be better, since y might have multiple columns:
select x, y
from the_table
where 'a' in (select z from y)
This would probably have pros and cons in practice.
> I don't think MS could lock its developer army in a hotel and tell
> them to make sql a little more relational:) They have two choices.
> Either buy a relational system (like D4) or start from the ground up
> to
> develop one. The gulf between a relational system and sql is too great
> to try to simply make changes in sql server. Which ever major vendor
> does either will 'own' application development :)
Why? The syntax extensions seem straightforward, provided that it can
be implemented reasonably efficiently.
Navigation:
[Reply to this message]
|