Re: Null and Void() - Or, Abandon All Hope Ye Who allow

Berend Tober wrote:
> Florian G. Pflug wrote:
>  > dananrg@yahoo.com wrote:
>  >
>  >> Date and Pascal hate nulls.
>  >
>  > ...the functions described by those functional dependencies are
>  > not required to be defined for every possible value - let's say you have
>  > a function dependency A -> B - meaning that whenever you know the value
>  > of column A, then there is _at_most_ one value for column BNormalization
>  > basically tells you to model that function dependency as a
>  > table containing fields A and B, and make A the primary key.
>  >
>  > Now, if there is no B for a specific value of A, then this table will
>  > just not contain a record for this value of A. But if you allow
>  > NULL-values, then suddently there are _two_ different ways to express
>  > "I don't know what B is for this A". You could either have a record with
>  > the A-value in question, and with B null, or you could have _no_ record
>  > with the A-value in question.
>  >

> But in the former case, you affirm the existence and your knowledge of
> the second A-value; in the latter case you affirm ignorance of the
> second A-value. The two-column example may be useful for theoretical
> discussion, but in practise likely more columns exist so that NULL can
> represent incomplete data that may be determined later for a particular
> row when you still need to commit the column values already known.
I came up with the two-column example because it's the simplest example
possible. For larger tables you _could_ split them into n tables (at
most one per field). If not saying I'd do that - just that it's possible
and that it's basically what Date and Pascal suggest.

 > For
> instance, in response to customer demands, it may be required that a new
> employee begins work on projects right away, even though we have only
> basic identifying information, like say, their name. This gives us
> enough to create a new employee row, start recording their labor hours
> worked for billing purposes, and to cut checks for travel expenses. We
> eventually need date of birth, social security number, and other
> information, but as a practical matter those columns can certainly be
> committed NULL initially.
Well, yes - as I said, using null values gives you more flexibility. But
still, you _can_ shoot yourself in the foot by using them - that's why
it's still good to know why some people oppose them, even if you don't
share their point of view. But of course, "rm -r $(PGDATA)" is a more
efficient way to shoot yourself in the foot, and will probably harm more
then using null ;-)

greetings, Florian Pflug