Re: Quote of the Week

"--CELKO--" <jcelko212_at_earthlink.net> wrote in message news:18c7b3c2.0405122047.327f3b56_at_posting.google.com...
> >> Yes, Fabian can be a pain, even to the point of sharp, unwarranted
> words. <
>
> I believe that he still holds second place for being kicked out of the
> most CompuServe forums. First place belongs to a lady with logorhea
> who would get off of her medication and would type insults to random
> people for days until she collapsed.
>
> >> But his criticism of you is well founded AFAICG. <<
>
> Actually, I don't think so. Here is why:
>
> 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.

In what sense is mandating NULL a spec? Of course that rules out anyone not allowing nulls...

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

An arbitrary dummy date, or a special value? And in what sense is that any more false than a null (it sounds like the design you imply is suspect, and could be resolved either with a relation-valued attribute of promotions, or a special value still in the domain of DATE).

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

That's unfortunate.

> 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 qualification was removed when I was quotes on dbdebunk,
> completely mis-representing my position. Then in a reply to an email
> on 1NF, Fabian made reference to the same kind of thinking!

Ironically, Date essentially agrees with that assessment of 1NF (not in SQL, but relational) in his "What First Normal Form REALLY Means" paper.

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

I doubt it. Even XSLT is non-procedural, and yet I think it was the originator of XPath. Procedural how?

> In short,
> it is the worst way to model a tree in a set-oriented language,

What is a better way? I'm not familiar with this discussion.

> but to give it up he would have to acknowledge either path enumeration or
> nested sets models, and that he missed it.

Too bad he doesn't acknowledge it. Do such constraints require a TCLOSE type of operator?

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

They're shorthand, I believe, not extensions. Very useful shorthand, though.

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

So what non-chronon model is better? I've not read Date's temporal book, just his Intro to DB Systems.

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

So SQL-92 is relational?

• erk