Re: 3vl 2vl and NULL

Look Hugo - I think we're each getting sick of this now. Please look at the discussion between Codd & Date, and in particular the discussion about "not known" and "known not". Don't try to tell me that there is no such thing as a
known-to-be-empty-non-string-value-respresented-by-NULL in SQL. You'd be wasting everybody's time. If you try to tell me that a known-to-be-empty-non-string-value-represented-by-NULL is exactly the same as a
non-known-could-be-empty-I-just-don't-know-what-the-hell-it-is-but-I-need-*something*-in-this-cell-represented-by-NULL then you'd be wasting everybody's time. Much of the discussion between Codd & Date (see link to article in dbdebunk in the other thread) concerned the *fact* that NULL can be interpreted to mean things other than simply "unknown". If I look at my empty mug I can truthfully say that there is an absence of any liquid in it - because it's empty. That does *not* mean I don't know what's in it. I don't have to look for any other facts. It is, very plainly and obviously, empty. If I have a rule that I only store data (known facts) in a database then I'll know that where I have a NULL then the NULL represents an absence of any value. It most certainly will not signify that I have an unknown value. It will signify that there is no value where one would normally be expected. It will signify that the "thing" is empty. I will be keeping my database "pure", in that I will only be recording data (known facts). Any questions I ask of my database will provide absolute yes/no known truth - or it will simply and honestly tell me that it has insufficient data. If, for instance, I ask for information on countries with or without Weapons of Mass Destruction, there will be some countries - like the USA - with known-non-empty values for WMD attributes, some - like New Zealand - with known-empty-NULL values for WMD attributes, and some with no data at all - because there simply is no reliable information. I make the point again - there is no place in a database for unknown values - and pretending otherwise will inevitably lead to problems, sometimes major problems. MVL is dangerous.

Mike.

Hugo Kornelis wrote:

> On 5 Dec 2005 18:17:49 -0800, michael_at_preece.net wrote:
>
> >
> >Hugo Kornelis wrote:
> >
> >> On 4 Dec 2005 17:57:01 -0800, michael_at_preece.net wrote:
> >>
> >> (snip)
> >> >OK. There is one fundamental problem with this. Some of those NULLs in
> >> >those tuples might represent that we know something is empty - so it
> >> >has to be treated as a known value. All NULLs are not created equal.
> >>
> >> <sigh>
> >>
> >> Hi Mike,
> >>
> >> No. If something is known to be empty, it's not stored as NULL. At least
> >> not in SQL databases (which this thread is about, IIRC).
> >>
> >> If a comment is empty, iut's stored as the empty string (''). If a
> >> container is empty, it's contents is stored as zero gallons (0). Dates
> >> can't be empty. (Days can be, though - that's stored as an absence of
> >> rows in the Events table).
> >>
> >> Best, Hugo
> >
> >What type of liquid is stored in an empty mug? Is it "unknown"? No - it
> >is not an unknown type of liquid. It is no liquid. The value of the
> >"liquid" column for the row would be empty. It would be NULL.
> >
> >Super,
> >Mike.
>
> Hi Mike,
>
> As JOG already points out, the contents of a mug should be in a seperate
> subtype table for non-empty mugs. Mugs have a row in the NonEmptyMugs
> table iff Mugs.Contents > 0 cc.
>
> But let's suppose that you still prefer to keep the Liquid column in
> Mugs. Let's say, for performance reasons. Or because your boss forces
> you at gunpoint. Whatever. In that case, the Mugs.Liquid column would be
> NULL (not empty) if the mug is empty. This still means nothing more than
> "no value here". As I already said before: if you feel the need to know
> *why* there's no value in Mugs.Liquid, then you'll have to use an extra
> column for it. And hey! in this case there already is such a column.
> Look here: Mugs.Contents == 0 cc. Now we know *why* there was no value
> in Mugs.Liquid for this mug. Not by looking at the NULL, but by looking
> at another column and infering a conclusion that we (as domain experts)
> can draw from the data present, but that the database itself could never
> conclude.
>
> Best, Hugo
> --
>
> (Remove _NO_ and _SPAM_ to get my e-mail address)
Received on Wed Dec 07 2005 - 02:59:07 CET