Re: 3vl 2vl and NULL

"Jon Heggland" <heggland_at_idi.ntnu.no> wrote in message news:MPG.1e0b5332d42db4bf98974a_at_news.ntnu.no...
> In article <g4a1q158gmk0vnklaogelgfcpgsnkb027q_at_4ax.com>,

> I'd rather say that the important thing is that Uncle Vernon *has* an
> age, even if nobody (including himself) knows it.

The fact that Vernon *has* an age is a "fact about facts". You can make that assertion, because you know that people have ages, and Vernon is a person. All what I've just said could be recorded in a database. But would it be data or metadata?

 > Then they find examples
> > where there's other reasons to use NULL (inapplicable, e.g.), which
> > leads to the discussion that there should be two, three, or whatever
> > number of NULLs to denote the various reasons why data can be missing.
>
> I thought it was commonly accepted that "inapplicable NULLs" are an
> artifact of wrong database design. Inapplicable data are *not* missing.
> Furthermore, to use SQL NULLs for "inapplicable" does not make sense
> with the current rules; that is my point. It should be an error to try
> to perform an operation on inapplicable data; it should not just result
> in another NULL or in an UNKNOWN truth value.

It's not commonly accpted. It's commonly accepted that, for every database that end up with
"missing" values due to inapplicable cells, there exists an alternate design that would have expressed the same inapplicability by an omitted (not missing) row, rather than by an omitted value in an existing row.

What's not commonly accpeted is that the design that contemplates inapplicable data is "wrong". Received on Thu Dec 15 2005 - 10:55:23 CET