Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

From: David Cressey <>
Date: Thu, 01 Jun 2006 20:43:43 GMT
Message-ID: <3kIfg.94$Eo3.60_at_trndny02>

"Bob Badour" <> wrote in message news:uwHfg.16134$
> David Cressey wrote:
> > "Cimode" <> wrote in message
> >
> >
> >>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
> > pretty well by SQL, to the extend that SQL deals with them at all.
> > 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
> > 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.

I thought the diffence between a "domain" and a "type" was precisely that types include operators while domains do not. Received on Thu Jun 01 2006 - 22:43:43 CEST

Original text of this message