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

--- Andrew Gould <andrewgould@yahoo.com> wrote:

> --- Berend Tober <btober@seaworthysys.com> 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. 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