Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

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 15:17:04 -0700
Message-ID: <1149200224.203828.273830@g10g2000cwb.googlegroups.com>


Sorry TYPO (my mistake)
<<Unfortunately, CREATE DOMAIN is a relational domain but a SQL domain...>>
should read
<<Unfortunately, CREATE DOMAIN does NOT refer to a relational domain but to a SQL domain...>>In a word CREATE DOMAIN is an empty shell on a relational standpoint.

Cimode wrote:
> Thank you for your feedback...
>
> <<Bad duplicate treatment can be avoided by
> judicious use of primary keys and the "distinct" feature>>
> Absolutely. However these are turnaround solutions to insure the
> integrity of data that are to implemented in applicative DBMS code when
> they should be dealt with by the DBMS. As a result, during system life
> cycle what should be done once is often done each time a new view is
> defined which defeats the purpose of a DBMS. A practical problem
> arising happens for instance when a developper leaves a company. If
> this developper has participated in the design (or lack of design)
> process then this developper is probably aware of all the special
> conditions and features he should add (DISTINCT, IS NULL IS NOT NULL)
> to make count results correct. But as soon as this developper leaves
> the company his knowledge often get lost which in most cases will make
> the next generation of count queries return false results because the
> new developper will not be necessarily aware of the conditions required
> to make results correct. In a word the use of features such as
> distinct are already meaning a failure on a relational standpoint. In
> the case of DISTINCT, their suggested use was made by Codd as a warning
> about that limitation.
>
> <<NULLS are handled pretty well by SQL>>
> The problem is not whether NULL values are well handled by SQL, the
> problem is that NULL values are SQL's only way of representing missing
> information and that this way is a poor one because relational
> predicate logic suporting relational model does not support on three
> valued logic on which SQL NULLS are essentially based.
>
> <<OTOH, some of the SQL DBMS products don't deal with missing data very
> well>>
> True, but I would phrase it otherwise. I would rather say that some
> implementation are more *aware* of SQL limitations to handle missing
> data and that some implementation have a higher automation of getaounrd
> solutions/
>
> << But what really baffles me is "lack of domain definition"? CREATE
> DOMAIN
> seems pretty straightforward to me... am I missing something?>>
> Unfortunately, CREATE DOMAIN is a relational domain but a SQL domain
> which is not the same. First they support only primitive data types
> (date/time where created only in SQL92). Second, SQL domain data types
> are only derivation of primitive types. Additionally, SQL domains do
> not allow to define user defined operators..As a proof of this
> limitation several SQL DBMS do not implement can not for instance
> define a table according using as a data type another table (and they
> can even less define operators for these tables).
>
>
>
> 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?
Received on Thu Jun 01 2006 - 17:17:04 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US