Re: What does this NULL mean?

From: paul c <toledobythesea_at_oohay.ac>
Date: Sun, 11 Dec 2005 15:58:39 GMT
Message-ID: <P0Ymf.87826$ki.29835_at_pd7tw2no>


John Eggert wrote:
>
> ... How can I capture the same data (the missing information
> IS the data) in a database? Just to be clear, the empty cell in the
> completed operator's report sheet IS USEFULL DATA. ...
 > ...
> ... How can I further normalize a single number?

I think this is a great question. Undoubtedly my answer won't be considered so great but my answer is to make it a first-class fact, a fact in its own right.

IE., if both situations are deemed important to the application, play the ball where it lies.

Codd's revision seems to have created more questions than it answered but his original insight seems very much oriented around the idea that regularized, like facts could be dealt with efficiently by computers with their talent for repetition.

It seems he went to some pains to prevent the union of unlike facts, eg. you can join ('and') any two relations but not union them unless they are of the same kind.

The dog in the night is another good example. It might seem that Clouseau was a better detective than Holmes, since there were fewer secondary murders once he got on a case. My theory is that this had more to do with Lestrade's chronic confusion. It wasn't that the ground was littered with bodies after Holmes got on the case, rather it was because Lestrade's database was chock full of nulls and Holmes had to waste a lot of time re-casting it.

cheers,
p

ps: Personally, I don't have a problem, on paper at least, with a relational op sometimes producing two unlike relations as a result. I gather Codd wanted a stricter version of closure for practical reasons, not theoretical reasons. Even if the practical consideration seems to sometimes paint one into a corner, I don't see how nulls can be regarded as any kind of theoretical solution. Received on Sun Dec 11 2005 - 16:58:39 CET

Original text of this message