If you want to read more religious wars on this subject, look for some of
Chris Date's writings on nulls.

If you want to avoid arguments, eliminate all nulls (and "not applicable"
entries) from your data model by introducing more tables. You will then be
able to reason about anything in your database with 2 valued logic, which
has the notable advantage of being simple enough to use and understand.

As you have noticed, nulls could mean "unknown" (as Helen suggests) or "not
applicable" (as you suggest). The SQL "standard" basically has decided on
three valued logic where nulls mean "unknown". This is not consistent with
three valued logic where nulls mean "not applicable", as you have noticed.

There have been suggestions that sql should be based on 4 valued logic with
separate tokens for "unknown" and "not applicable" but due to the extreme
difficulty of humans coming to any valid conclusions in such systems AFAIK
no one has implemented one, at least in a commercial system.

I suspect a moments thought will convince you that the "equality" of
not-applicable entries is of a somewhat different nature than equality of
known values and that it as least plausible to have a 4th truth value to
model this more precisely.

thanks
david jencks

On 2002.12.22 08:23:44 -0500 Lauri Zoova wrote:
> Since you raised a few new questions i'll try to explain myself:
>
> Helen Borrie wrote:
> >>>[...]
> >>>Just remember that if new.field and old.field are both null, you won't
> get
> >>>True on an equivalence comparison either...
> >>
> >>So we are back at the beginning :)
> >
> > We are at fundamentals, I suppose you could say. Unknown == unknown
> cannot
> > be evaluated as equal, e.g. Lauri's phone number == Helen's phone
> number if
> > you don't know either of them.
> > [...]
> > How do you consider "valueless state" and "unknown" to be different,
> logically?
>
> Extending the phone number example:
> Lauri's phone number = Helen's phone number, if i know that neither of
> us has a phone number. This is the case with null. (IMHO)
>
> >>I really can not think of any use for unknown state or a boolean
> >>condition that can evaluate to unknown. I guess it's my limited mind
> :))
> >
> > Turn your thinking around the other way. The state of data is always
> > KNOWN: it has a value or it has no known value. It would be very
> > restrictive if "no known value" were predicated as if it could be
> evaluated
> > as "something" - apart from the untruth of making null pose as some
> sort of
> > value.
>
> No. There should not be "no known value", but "no value" and "no value"
> should be considered different from "value" not unknown. The possibility
> of unknown result in boolean evaluation is what i'm against of.
> There can't be a field has a state of null and at the same time has a
> value, correct?
>
> And (un)truth is only ones opinion.. so it has no real value - truth is
> null :P
>
>
> BR,
> Lauri
>
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
>