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

From: JOG <jog_at_cs.nott.ac.uk>
Date: 17 Nov 2005 16:59:19 -0800
Message-ID: <1132275559.630209.167920_at_f14g2000cwb.googlegroups.com>


Hugo Kornelis wrote:
> On 17 Nov 2005 03:39:01 -0800, JOG wrote:
>
> >I think nulls may have been done to death in the literature. Date,
> >Darwen and Pascal have written reams on the matter (and convincingly so
> >- I don't think anyone would argue they are theoretically correct, just
> >whether practically it matters). The problems all arise from english,
> >and how we formulate sentences. Consider:
> >
> >A) The dog's colour is black
> >B) The dog's colour is unknown
>
> Hi JOG,
>
> This has nothing to do with Null. Null can't be used to represent the
> fact "The dog's colour is unknown". You should represent that by adding
> an extra column. (And I'm sure that some programmers would consider
> allowing "unknown" in the domain of colors -- but YUCK).

I think we may just be agreeing there hugo. My point was that this is exactly what people _try_ to use a null for, where they clearly should not.

> [snip]
> A') The dog's colour is black
> B') The dog's colour is
>
> And that is where most people are tempted to finish the sentence with
> "unknown" - but there's no guarantee that they are right when they do
> so.

eh? If you can't finish sentence b, then the only fact that you _can_ possibly state is that the dogs colour is unknown (or rather the dog has an unknown or inapplicable property). Leaving a blank means you are not fulfilling the tables predicate, and the haemoragged tuple hence has no place being entered at all.

Interestingly there has been a shift in views over the last decade, and students are now generally taught as standard that columns should be automatically specified as NOT NULL, more in line with the Date, Darwen, Pascal cohort, rather than Codd's 3VL standpoint. Received on Fri Nov 18 2005 - 01:59:19 CET

Original text of this message