Re: Proposal: 6NF

"Hugo Kornelis" <hugo_at_perFact.REMOVETHIS.info.INVALID> wrote in message news:0n10j2dk19fibufr8agj3ah5qee6rpm444_at_4ax.com...
> On Fri, 13 Oct 2006 04:17:48 GMT, David Cressey wrote:
>
> >
> >"Hugo Kornelis" wrote:
> >
> >
> >>sloppiness in the hands of the unwashed!
> >>
> >> If there was any chance to get this changed, I'd favor a mandatory
> >> inclusion of explicit NULL or NOT NULL for every column.
> >
> >If I could go back in time and get it right to begin with, here's what
I'd
> >favor:
> >
> >Get rid of NOT NULL as a column property.
> >Add a new key word, OPTIONAL that, as part of a column definition,
permits
> >omission of the value, a la NULL. By default, all columns have a NOT
NULL
> >constraint unless overridden with the OPTIONAL property.
> >
> >Get rid of the Boolean value UNKNOWN.
> >Evaluate booleans that can be evaluated to either TRUE or FALSE. If a
> >Boolean expression cannot be evaluated, don't return any value at all.
> >If there's no trapping mechanism, then return NULL, indicating that the
> >expression has no value.
>
> Hi David,
>
> Would NULL as a result from a boolean expression differ only in name
> from the current UNKNOWN, or would it actually behave differently? For
> example, what would the result be of the boolean expression:
> (1 > 2) AND (3 = NULL) AND (4 < 5)
> or, shorter,
> TRUE AND NULL AND FALSE
>

It's a good question, but I don't have a good answer. My guess is that TRUE AND NULL AND FALSE would have to yield NULL. NULL isn't "TRUE or FALSE but we don't know which". It's the absence of a value.

What I don't like about UNKNOWN is that it isn't distinct from TRUE, FALSE. I don't have a problem with 3VL. I just have a problem with the domain {TRUE, FALSE, UNKNOWN}. It's a poorly defined domain.

I have another slant on the whole thing. A while ago Marshall suggested and "aggregate AND" that is not the same thing as N-ary and, you'll recall. Let's call it "SIGMAND" (yuk, yuk). It takes a list of booleans.

SIGMAND (TRUE, NULL, FALSE) evaluates to SIGMAND (TRUE, FALSE) which evalutes to FALSE.

The great unwashed could probably tie themselves in knots with this, just as they do with SQL in its present state. It's not py purpose to protect the great unwashed from themselves.

> >It's probably to late for this kind of surgery on SQL.
>
> Aye. But we can dream...
>

Agreed. We can learn from our mistakes, or we can repeat them.

There are people who want to stay with SQL forever. There are others who want to dismiss SQL as if it had been merely a bad dream. I don't follow either of them. Received on Sat Oct 14 2006 - 20:32:44 CEST