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

--- Andrew Gould <andrewgould(at)yahoo(dot)com> wrote:

> --- Berend Tober <btober(at)seaworthysys(dot)com> wrote:
>
> > Florian G. Pflug wrote:
> > > dananrg(at)yahoo(dot)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. 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.
> >
> > Regards,
> > Berend Tober
> > 860-767-0700 x118
> >
>
> Null values should be allowed for any information
> that
> may not be known at the time of data entry.
> However,
> any data field that falls into this category should
> not be required to define the relationships between
> tables. This is a case where the database design
> must
> reflect the limitations of operational processes.
>
> Andrew Gould
>

I need to temper my own response. I was referring to
relationships between tables where both tables contain
operational data. The use of reference tables, such
as code lookup tables, is a huge exception to my
comment.

Andrew Gould