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 14:00:37 -0700
Message-ID: <1149195637.347974.125680@h76g2000cwa.googlegroups.com>


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 - 16:00:37 CDT

Original text of this message

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