Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
Date: 1 Jun 2006 14:00:37 -0700
Message-ID: <1149195637.347974.125680_at_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.
<<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 - 23:00:37 CEST