Re: boolean datatype ... wtf?

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 Received on Wed Oct 06 2010 - 00:43:32 CEST