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

From: Cimode <cimode_at_hotmail.com>
Date: 1 Jun 2006 14:11:57 -0700
Message-ID: <1149196317.261087.221940_at_i39g2000cwa.googlegroups.com>


<< I thought the diffence between a "domain" and a "type" was precisely that
 types include operators while domains do not.>> Actually you can view domains as user defined data types that are of a user defined complexity and handling. They certainly rely on operators for operations such as intersect.

David Cressey wrote:
> "Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message
> news:uwHfg.16134$A26.374329_at_ursa-nb00s0.nbnet.nb.ca...
> > 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.

>

> 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 - 23:11:57 CEST

Original text of this message