OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Data storage, data exchange, data manipulation



[Jeff Lowery]

> > Remember, there's a big difference between the "relational
> > model" and SQL
> > (just ask C.J. Date).  Which one are you talking about here?
> >
> > Tom P
>
> I've thought of SQL DDL as one physical representation of a relational
> model, but I think you're hinting at something I need to read. Spill the
> beans, Tom... it may better inform the debate.
>

OK, here goes.  There are really two different questions here:

1) Does the newest version of SQL reflect "the" relational model?  The
answer seems to be "no" - for an excellent review of the relationship of
SQL1999 to past dbms practices, see Mike Gorman's paper:

"Great News, The Relational Model is Dead (159K)
This 24 page paper shows how SQL1999 is clearly NO LONGER relational. Rather
it includes aspects of the Codasyl network, hierarchical, and independent
logical file data models as well. "

http://www.wiscorp.com/sql99.html

Let me just quote from the ending of this paper, since much of it could
apply to XML data as well:

"While processing speeds will dramatically improve with SQL:1999 conforming
DBMSs, the
effort and processing time effort required to accomplish database redesigns
and reorganizations will
dramatically increase.

In short, we are returning to the past. That is, the data structures of the
network and
independent logical file DBMSs. While we will see increased performance for
well designed and highly
tuned databases, we will also see the return of significant designer and
analyst time for database design and redesigns.

Keith Hare of JCC Consulting (www.jcc.com), a long time member of H2 and a
user of Vax
DBMS products put it best when he said, "With SQL:1999 you can get the best
of both worlds and of
course, you can get the worst of both worlds. It is up to the database
practitioners to do the right thing." "

2) Does the older SQL that most of us are probably talking about adequately
reflect "the" relational model.  This is the domain of my original remarks
about C.J.Date's position.  Date has published a lot about this subject over
the years.  The most recent is in "The Third Manifesto" by C. J. Date and
Hugh Darwen, Addison-Wesley 2000.  Allow me to quote:

"... the hopelessness of continuing to follow a commonly accepted perversion
of [the relational] model, namely SQL, in fond pusuit of that model's
ideals."

"As just explained, it is a major thesis of the Manifesto that we need to
get away from SQL and back to our relational roots."

Now I don't have any references handy in which he spells out the details of
his aversion.  However, here is a quote from a ZDNet page at

http://www.zdnet.com/devhead/stories/articles/0,4413,2505718,00.html

"... but at this point we should explain that even though SQL is based on
Codd's relational model, it is not a full or faithful implementation of it.
(That's one reason the SQL-92 standard doesn't mention relations.) For
example, a SQL table is not exactly the same as a relation, because among
other things, a SQL table allows duplicate rows and relations don't have
duplicate tuples. Also, SQL doesn't support relational domains, although it
does support data types to some extent. "

Basically, relations aren't handled right, returned data which should be a
set isn't really a set, there can be confusion between values, domains, and
variables, domains aren't adequately handled, and many of the set operations
aren't included or are somewhat distorted.

BTW, Gorman makes the point that many vendors have arranged for you to
access their data using SQL even though they actually don't have a
relational engine at all - perhaps even a hierarchical or network engine.

Now in this new book, Date talks about how the relational model has evolved
since the original 1970s version.  His 2000 version apparently could provide
many features that SQL1999 has, since now you can have complex, structured
data types and values.  In Gorman's paper, where he compares SQL1999 to
"the" relational model, he's not comparing it to Date's updated version -
that might be interesting to do sometime.

How'd we do here, Jeff?  Is this what you asked for?

Cheers,

Tom P