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

From: x <x_at_not-exists.org>
Date: Thu, 24 Nov 2005 09:49:46 +0200
Message-ID: <dm3rb0$34o$1_at_domitilla.aioe.org>


"Hugo Kornelis" <hugo_at_pe_NO_rFact.in_SPAM_fo> wrote in message news:npl4o19n2roh7vnitsdhqr95p7gprlplou_at_4ax.com...
> On Mon, 21 Nov 2005 15:23:30 +0100, Alexandr Savinov wrote:
>
> >David Portas schrieb:
> >>>Yes, I acknowledge that we can deal with data without nulls but such an
> >>>approach would be very restricted and inconvenient.
> >>
> >>
> >> How "restricted"? You haven't provided an example of information that
> >> cannot be modelled without nulls (because no such information exists).
> >
> >I really like your argument: it does not exist because it cannot exist
> >(never).
> >
> >Actually I provided such an example. Here it is again in simplified
> >form. Assume that your problem domain consists of objects with two
> >attributes Colour and Weight. However, for any object it can be absent.
> >If we try to avoid nulls then we get a kind of 4 table design: 1 table
> >for colourless weighless objects, one for objects with both colour and
> >weight, and two tables for objects with one attribute absent.
> >
> >The first question: Is this design (4 tables) right price for having no
> >nulls? Do nulls deserve such an urgly design?
> (snip)
>
> Hi Alexandr,
>
> There is an alternative way. One that needs "only" three tables.
>
> 1. Objects - one column, the primary key for objects.
> 2. ObjectColors - two columns: one is both primary key and foreign key
> into Objects; the other holds a color
> 3. ObjectWeights - similar to ObjectColors.
>
> An object with no color and no weight gets a row in the Objects table
> only. Add a weight, and you get a row in ObjectWeights. Add a color, and
> a row is added to ObjectColors as well.

Then how do you distinguish among Objects that are known to have no Color and Objects that have an unknown Color ? Received on Thu Nov 24 2005 - 08:49:46 CET

Original text of this message