Re: Quote of the Week

> 1) Someone send Chris Date one of my very old SQL puzzles and wanted
> help with it. Chris answered it with his personal programming
> language rather than Standard SQL. The problem involved displaying
> the hire date and last promotion date for each employee in a
> personnel. The specs were to use a NULL, if the employee was a new
> hire. Since Chris Date's version of the Relational Model does not
> have NULLs, he used an arbitrary dummy date instead and thus created
> false information.

How exactly is a NULL any less arbitrary than a dummy value?

> I sent an email that discussed this problem and a new solution to
> dbdebunk.com which used the SQL-92 OUTER JOIN syntax that did not
> exist at the time of the original publication and a change in the
> table's DDL.
>
> It was never acknowledged, much less printed.

The solution involves NULLs and is therefore outside the relation model. What acknowledgement is warranted?

> 2) I made a remark in one of my books that SQL cannot technically
> violate 1NF because all columns are scalar datatypes. That was
> followed by detailed remarks as to how programmers are so used to
> thinking in terms of arrays and lists that they "fake it" with various
> tricks (numbered column names, strings of Comma separated values,
> etc.)

The fact that you claim SQL cannot violate 1NF because all columns are defined on scalar types betrays a fundamental misunderstanding of 1NF, and *that* is the point.

> 3) He still advocates an adjacency model for trees. Unfortunately, he
> does not given all the constraints needed to assure that such a table
> is actually a tree and not a general graph, nor does he mention that
> you **must** use procedural code to manipulate that model. In short,
> it is the worst way to model a tree in a set-oriented language, but to
> give it up he would have to acknowledge either path enumeration or
> nested sets models, and that he missed it.

It does not require procedural code, it requires a language that is capable of expressing transitive closure (or some sort of recursion at the very least). SQL is not such a language. The required constraint can be trivially expressed given such a language. Do you honestly believe Chris Date doesn't know the difference between a tree and a general graph? By the way, how do you justify claiming SQL is a set-oriented language when it's data structure is a bag?

> 4) He supports Chris Date's temporal model, which advocates a chronon
> model for temporal data and some weird extensions to the relational
> model for them. Even before 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, so time is made up of
> durations that cannot be defined as countable sets of points.

The domain of integers is infinite, but we are quite content to model it with a finite set. In what way is this different?

There are *no* extensions to the relational model proposed in the book Temporal Data and the Relation Model. This is quite different from Rick Snodgrass's approach, which requires such Information Principle violating notions as hidden columns. All the operators introduced in the temporal book are shorthands for more detailed *relational* expressions.

From Temporal Data and the Relational Model, p. 56 "In other words, the approach to temporal databases that we advocate invovles no changes to the classical relational model!"

So what extensions precisely are you claiming are introduced by Date, Darwen and Lorentzos' work in this area?

> 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.

You continue to confuse intellectual criticism with personal attack.

> 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.

Therein lies the problem. There are no alternative versions of the relational model. All the so-called extensions you are referring to are *departures* from the relational model, not extensions to it. Received on Fri May 14 2004 - 04:26:58 CEST