Re: Quote of the Week

:-) Are you reviving the old Date-Celko arguments? Actually the points you enumerated are a clean evidence why one should not try to equate the capabilities of relational model with existing SQL flavors including the pervasive ANSI standard.

>> 1) Someone send Chris Date one of my very old SQL puzzles ... thus
created false information. <<

Here is the relevant links you are referring to: http://www.dbdebunk.com/page/page/666711.htm http://www.dbdebunk.com/page/page/754901.htm

The problem was with the specs requiring you to use a NULL, which has no *meaning* in a relational database. Again, this goes to the territory where the usage of NULLs to assert a meaning, which has been considered a flawed approach by many. NULLs in an OUTER JOIN result set is somewhat of a horror story, unless the "nulls as meta-data" approach may be considered by some as an alternative.

>> 2) I made a remark in one of my books that SQL cannot technically
violate 1NF because all columns are scalar atatype...an email on 1NF, Fabian made reference to the same kind of thinking! <<

You are correct and the references in recent versions of your book stands to your credit. However, you do not divulge any information regarding the reason why such faking is being tried by SQL programmers. The real problem lies in the inability of SQL to support true datatypes, except the built-in ones and a blatant assertion about 1NF violation using a set of columns in SQL changes the very nature of the problem.

>> 3) He still advocates an adjacency model ...you **must** use procedural
code to manipulate that model...the worst way to model a tree in a set-oriented language,.... <<

Using SQL with its current capabilities, yes, one must use procedural code; however that does not mean given a relational operator (similar to TCLOSE) or an EXPLODE() similar to the BOM explosion, one cannot easily manipulate such a representation declaratively. Perhaps, nested sets may be the best approach applicable in SQL, but then Again, the limitation of adjacency list lies in the inability of SQL to provide sufficient constraint declarations and relational operators, and not with the logical representation itself.

:-) Who would be responsible for the failure to acknowledge that?

>> 4) He supports Chris Date's temporal model, ..... Rick Snodgrass did his
work in the field, Zeno's paradoxes and Einstein's physics showed that time is a continuum and not a set of discrete points.... <<

I got a copy of Snodgrass' book (which is out of print, I guess) from his website at: http://www.cs.arizona.edu/people/rts/

An excellent book for SQL programmers, with details on constructing intervals, instants and a lot of examples with overlaps and temporal partitioning. However, I am not sure how or why this has any relevance to the Date/ Darwen/ Lorentzos book which gives a new relational perspective to the temporal data representations with suggestions for new types, operators etc. Also, not sure about the "weird" extensions, except that Date proposes certain additional shorthands like PACK, UNPACK, COLLAPSE etc. The book has some new types like the INTERVAL type and interval-valued attributes which will/can never be a part of SQL.

>> 5) If anyone mentions my name to him, he will simply insult me without
giving them a reason. Example: on dbdebunk.com,one of his replies to an email that mentioned my name as a source for SQL info was simply "Stay away from Celko!" and nothing else. <<

I agree that this may a poor precedence, but some of your communications with Date, esp. the ones on types and normalization theory has some bad connotations. For example, in Date's Relational writing series #3 & #4, he discusses some of your letters, which has been debunked for lack of clarity and substance. From the online versions here are a couple of your interesting exchanges:

http://www.dbmsmag.com/dateltr.html
http://www.dbmsmag.com/9601d010.html
http://www.dbmsmag.com/9602d01.html
http://www.dbmsmag.com/9605d01.html

>> At least, I itemize differences in the SQL-92 (me), Chris Date and Ted
Codd versions of the RM and the various extensions to each one. <<

Actually, it looks like you are referring to the chapter on Relational Data Model in your book Data & Databases, but I can't think of a better reply than the critique by Date himself at: http://www.pgro.uk7.net/cjd6a.htm

--
Anith