Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> comp.databases.theory -> Re: So what's null then if it's not nothing?

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

From: <>
Date: 22 Nov 2005 15:34:44 -0800
Message-ID: <>

Oh dear... I *really* didn't want to have to re-enter the fray here, but when your words have been taken out of context...

Hugo Kornelis wrote:

> On 20 Nov 2005 19:58:44 -0800, wrote:
> >
> >Julian M wrote:
> >
> (snip)
> >
> >> NULL in SQL can seem tricky, but it is simple enough if viewed in terms
> >> of what is intended by the ANSI SQL92/99 standards.
> >> See drafts:
> >>
> >>
> >>
> >
> >Here's your problem...
> >
> >"A special value that is used to indicate the absence of any data
> >value."
> >
> >That's it right there. It doesn't make sense. The special value has to
> >be present doesn't it? So something is present. What is it? Is it an
> >indication that whatever it is is absent? Nope. If something is present
> >it's present. If it's absent it's absent.

This only makes sense if it
is interpreted to mean that it, whatever it is, is empty, or void, of any value. Absence is the problem word. If I want something to be absent I'll delete it from the database. If I want to record that something does not have any data value I'll record a null. Pick doesn't

need a special value to indicate this presence of a lack of any value -

it just uses a lack of any value. I don't have a problem with SQL implementations using a special value if they're intrinsically unable to record the lack of any value as a lack of any value.


"A value of the Boolean data type is either true or false. The truth value of unknown is sometimes represented by the null value."

Dodgy or what?! It would be better to use a large cumbersome robot waving its arms about saying "does not compute" than to use null for this.


PS. That's definitely it for me on this thread. Thanks and so long. </UNSNIP>

Note the use of CAPS on the UNSNIP to emphasize the deliberate attempt at obfuscation. You make a great point about the fact that a special value is used, when I do, in fact, go on to acknowledge that.

> Hi Mike,
> Pay more attention to what you read before you reply.

Oh the irony! I'll be keeping a keen eye out for what you snip and what you leave in your posts in future. It seems your snippage in this case was motivated by a need to "win" the argument - without regard to accuracy and completeness. Maybe it was designed for just this eventuallity - that I would be forced to respond...

> I'll use caps to

...try to win the argument if twisted logic fails

[remainder snipped as it was a distortion of the points I was making]


PS. To put this as clearly as I can :-

The presence of the special value is necessary (in some DBMSs) to indicate a fact. The fact is that we have no value. Unknown, on the other hand, equates to an absence of any facts. Can you see that "unknown" is therefore not equal to "no value"? If not, I would be happy to expound on this. The standard would have been better had it defined NULL as "No value. An empty set. A special value may be used to indicate its presence.".

Regarding the use of NULL to record a boolean truth of unknown... The fact is, in this case, that we know something is neither true nor false. Whether that is because it is inapplicable, or simply because we have insufficient data, or for any other reason, we do know something - even if it's only in terms of what it is not equal to. I really don't think it is at all wise to confuse this fact (that something is neither true nor false) with having no value. I have no recommendation as to how this should be handled - other than to suggest it is a bad mistake to use NULL for it. Perhaps it just depends. Received on Tue Nov 22 2005 - 17:34:44 CST

Original text of this message