Re: So what's null then if it's not nothing?

From: Frank Hamersley <terabitemightbe_at_bigpond.com>
Date: Fri, 09 Dec 2005 08:06:13 GMT
Message-ID: <VVamf.15221$ea6.12170@news-server.bigpond.net.au>

Jon Heggland wrote:
> In article <UgClf.13909$ea6.6355_at_news-server.bigpond.net.au>,
> terabitemightbe_at_bigpond.com says...
>

>>The trouble with your definition is that it is nonsensical - more than a 
>>bit like what Alice encountered!

>
> I don't think you have understood the nature of our discussion.

Maybe, maybe not (pun intended)! However the fact remains that your assertion herein quoted...

<Quote>There is another domain, consisting of the values {TRUE, UNKNOWN, FALSE }, which I called "3VL Boolean".</Quote>

... is nonsense! Call it what you will, the bottom line remains that the Boolean domain (since well before even Socrates was a boy) has only 2 possible values. It is and always will be a binary domain. The only place where it has more or less values in its domain is "Through the Looking Glass". Per my prior explanation, seeing NULL held by an boolean attribute is not inconsistent with the above. The gross misnomer in all of this discussion is to start with an assumption that a 3 Value Logic system presumes a 3 Value Domain. Your bad?

>>The root problem is that the "UNKNOWN" (aka NULL) itself is not and 
>>never will be a member of that or any other domain.  Accordingly others 
>>have called is a "Special" value.

>
> You misunderstand. In 3VL, there are three truth values, often denoted
> by the symbols 0, 1 and 2. Neither of those is identical to the
> mysterious SQL NULL; on that, both vc and I agree (I think).

The mystery you refer to is a mystery to me! What is really cute that the equivalence test ((mystery == mystery) is False) unlike ((NULL == NULL) is NULL) ;-)

> Perhaps you are thinking about the "obvious" implementation of booleans
> in SQL, where you would have two possible values---TRUE and FALSE---and
> the possibility to set the attribute to NULL, like an attribute of any
> other type in SQL. That is a very different thing, though this
> difference may actually be hard "to get".

Yes I guess I am being obvious. Is there a better way?

> FWIW, I agree that { TRUE, FALSE, NULL }---using "NULL" in its usual SQL
> sense---is not a domain, because NULL is not a value.
>
>

>>When the attribute value does become known (lets say it is "MAYBE") then 
>>it is no longer UNKNOWN, it is MAYBE and it is a member of the domain 
>>(YES, NO, MAYBE) (sic) :-)

>
> Or are you just suggesting that I should use MAYBE instead of UNKNOWN as
> a more user-friendly name for the third 3VL value that is neither TRUE
> nor FALSE? It seems strange (to put it mildly) to say that my
> "definition" is "nonsensical" for that reason alone.

Yes - as writ before NULL is not a candidate for the role of MAYBE. The wag in me has wondered about the 4VL extension to (YES | NO | MAYBE | MAYBENOT). The truth table for this would be mindbending, no?

>>Personally I don't understand why NULL is so hard "to get".

>
> It's not that hard to memorise the rules about NULLs in SQL, but they
> are not particularly intuitive or self-evident. But it makes sense if
> you squint a little and don't think too hard about it, I suppose. :) Or
> YMMV with regard to what you mean by "to get".

True! Cryptic precepts are an anathema to reliable and considered adoption of evident principals by an unwashed novice - in other words the KISS principle rules. However, there are some things in this universe that are irreducible, and at that point I make no apology for those who don't "get it". I reckon that Codd has actually done a much better job that all his detractors by picking the so called 3VL position as against the ardent 2VL or runaway nVL types who even with the benefit of time haven't been able to substantively dent his principals (food for another thread perhaps). Even a mere mortal like me can get his mind around the truth tables for 3VL, but when I look at the 2VL and nVL counter proposals, I am immediately mindful of porcine aeronauts!

Cheers, Frank. Received on Fri Dec 09 2005 - 02:06:13 CST