Re: What does this NULL mean?

From: Frank Hamersley <terabitemightbe_at_bigpond.com>
Date: Thu, 15 Dec 2005 05:49:55 GMT
Message-ID: <7u7of.2299$V7.264_at_news-server.bigpond.net.au>


mountain man wrote:
[..]
> Theorists like Date who think the null should be rationalised
> out of existence have no demonstrated understanding of the
> database change management environment, and specifically
> the management of schema evolution and its consequences
> in regard to the generation of nulls.

Just picking up on a minor point that has been front of mind for some while - who in this place considers Date to be a credible theorist and especially to be accorded stature commensurate with a luminary?

Personally my introduction to material produced by him was as an undergrad when Intro to DB Systems (2nd Edition) was the course text. It, I presume, is still considered a significant book but having picked it up recently I came to the conclusion it is basically a catalogue of preexisting material. Right place, right time if you like, in terms of capturing Codd's Damascus event and a good presentation. However the genesis of his career was as an instructor not an architect or even an engineer.

Having read some of the free to air material attributed to him and his freely associated with colleagues I have my doubts that he should be accorded quite as much stature as perhaps is common today. To illustrate is quote from page 9 of the "Missing Info without Nulls" lecture notes presented by HD ...

"And we have reduced the salary part of the database to the simplest possible terms. Yes, some of the complicated queries get more difficult now, because we might have to combine these tables back together again, but the simple queries, such as 'How much salary does each person (who has a known salary) earn?' and 'Who earns no salary?' become trivial."

So trivial remains trivial and complicated becomes near impossible. This type of progress I think conveys your point comprehensively Pete!

> People who construct database systems but do not maintain
> them, or have not maintained them for more than a few years,
> will never understand that the greatest entry point of nulls into
> the database is during change.

Ne'er a truer word wrote! Personally I try to manage backfilling (to simplify new queries dealing with old data) where possible without polluting history, but of course that is not always going to be possible.

> Change management or schema evolution is not adequately
> addressed by Date et al, however by the time they set forth
> the processes covered under this subject, it will become very
> apparent that the NULL will never be rationalised away, and
> it is better to therefore appropriately manage its identification,
> its existence and its resolution interactively.

Not adequately, or not at all? I haven't yet (and given my views above am unlikely to ever) shell out for their dissertations on Temporal affairs, but I wonder how they might approach the issue when the schema itself has temporal variability. I suspect to apply this to SQL-D if it ever materialises would lead to an exponential number of relvars with untold amounts of information buried in the metadata. Of course for an inaugural novelty (tautology intended) I could be wrong :-).

Cheers, Frank. Received on Thu Dec 15 2005 - 06:49:55 CET

Original text of this message