David Cressey wrote:
> "Cimode" <cimode_at_hotmail.com> wrote in message
> news:1149188800.056087.159770_at_h76g2000cwa.googlegroups.com...
>
>>Thank you for your feedback...
>>
>><<This is urban myth. SQL is widely criticised for its NULL and
>>duplicate
>>treatment. There is several more little annoying inconsistencies. >>
>>"myth" seems a strong word to me...It's true that SQL very apparent
>>drawbacks consists of poor duplicates treatment and poor handling of
>>missing data (NULL) but I do not believe these are the worst. Other
>>drawbacks appear more troubling to me into handling better relational
>>requirements are the fact that SQL neither correctly support domain
>>definition, nor it implements any real coherence of what relational
>>data types are.
>>The main impact is that a better integrity preservation, a core issue,
>>becomes very difficult to implement.
>
> I'm not following the above. Bad duplicate treatment can be avoided by
> judicious use of primary keys and the "distinct" feature. NULLS are handled
> pretty well by SQL, to the extend that SQL deals with them at all. OTOH,
> some of the SQL DBMS products don't deal with missing data very well.
>
> But what really baffles me is "lack of domain definition"? CREATE DOMAIN
> seems pretty straightforward to me...
> am I missing something?
I think you are missing the part where a domain is an arbitrary data
type complete with its own set of operations. You seem to have confused
the relational domain with the rudimentary aliasing facility that
actually made it into SQL using a similar name.
Received on Thu Jun 01 2006 - 14:48:42 CDT
