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