Re: boolean datatype ... wtf?

From: Brian <brian_at_selzer-software.com>
Date: Tue, 5 Oct 2010 16:12:12 -0700 (PDT)
Message-ID: <5f8ee076-235d-4bba-b5ed-4671dfc3f714_at_t20g2000yqa.googlegroups.com>


On Oct 5, 6:43 pm, Keith H Duggar <dug..._at_alum.mit.edu> wrote:
> On Oct 5, 5:06 pm, Brian <br..._at_selzer-software.com> wrote:
>
> > Here's another example for the null-haters.  Suppose that P{A,B,C} is
> > a table with key {A,B} that permits C to be null.  To eliminate the
> > null, it must first be determined whether there should be a value for
> > C or not--in other words, is each NULL in column C an applicable NULL,
> > or an inapplicable NULL.  So now you have P1{A,B,D} where D is a
> > boolean indicating whether there should be a value for C, and
> > P2{A,B,C} where C cannot be NULL, and P2[AB] IN P1[AB].  If you also
> > need to eliminate D, then you need P1{A,B}, P2{A,B} and P3{A,B,C},
> > with P2[AB] IN P1[AB] and P3[AB] IN P2[AB].  So if you disallow
> > boolean types too, you would need three tables and two interrelational
> > constraints to eliminate nulls from just one column!  Moreover, the
> > resulting schema may be in violation of POOD, since P1 and P2 have
> > exactly the same heading!
>
> Let's rephrase the above in plain language:
>
> Suppose we throw trash all around the inside of our house. In order
> to eliminate the trash we'll need to determine whether each item in
> the house is trash, non-trash, or smelly-trash. In other words, we
> are going to attach a note to each item. But these notes are just
> more trash! If you disallow notes then we will need a second house
> (or at least storage facility) into which we can move either the
> trash or the non-trash. But what about the smelly-trash?! It has the
> same look as normal trash!
>
> In other words, your post was truly stupid.
>
> KHD
I never said anything about trash. NULLs are not trash, they're indicators: no value here. Eliminating each requires not only splitting off the nullable column into a separate relation but also introducing a boolean indication to distinguish between inapplicable nulls and applicable nulls. The bottom line: if you're a null hater and a boolean hater, then you need two additional tables to eliminate each nullable column, along with two additional interrelational contraints. Are you denying that? Received on Wed Oct 06 2010 - 01:12:12 CEST

Original text of this message