Re: Proposal: 6NF

From: Cimode <cimode_at_hotmail.com>
Date: 1 Oct 2006 09:58:20 -0700
Message-ID: <1159721900.535892.263590_at_c28g2000cwb.googlegroups.com>


Not mine...Check McGoveran's on thethirdmanifesto.com

David Cressey wrote:
> "Cimode" <cimode_at_hotmail.com> wrote in message
> news:1159707552.227184.276470_at_k70g2000cwa.googlegroups.com...
> > Imaginary numbers are not values belonging to domain of reals.
> > Nevertherless they are values.
> >
> > NULLS are NOT values.
> >
> > NULLS is SQL's poor way of handling missing data by making arbirtrary
> > assumptions about what *should be there*. There is a number of
> > possible values greater than one for each NULL value stored in a
> > database and therefore predicate can not be validated (therefore you
> > have no facts in your database). In a way, one could conceive NULL's
> > as a occurrence of some random function in a limited set of
> > possibilities but certainy not as a value. To make your database state
> > facts about reallity under the form of predicate you use values that
> > belong to well defined domain of values that are derived from one
> > another.
> >
> > NULL is the carpet under which you hide the dirt of missing data
> > instead of throwing it to the trash. It is practical YES. But it has
> > the drawback of making your count results false if you, your team and
> > all people working on the db during the system life cycle, do not put
> > additional IS NULL/IS NOT NULL conditions in all procedures selecting
> > values from tables allowing NULLS. Adding such conditions kills
> > performance at overall server level. So. Result FALSE/ Performance
> > (Response Time/Concurrency) Down.. Do you still believe that NULLS are
> > a good idea?
> >
>
> What's your proposal for a systematic way of dealing with missing data?
Received on Sun Oct 01 2006 - 18:58:20 CEST

Original text of this message