Re: Proposal: 6NF

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Wed, 04 Oct 2006 12:50:52 GMT
Message-ID: <M6OUg.80$cz.1594@ursa-nb00s0.nbnet.nb.ca>

David Portas wrote:

> Brian Selzer wrote:
>

>>As far as performance goes, assuming that one of a or b or neither is
>>nullable, the performance of a join depends on the cardinalities of {i, a}
>>and {i, b}, the number of rows targeted in each, and the type of join--that
>>is, whether it's a loop join, a merge join, or a hash join.

Bullshit. First and foremost, the cost of the join depends on the physical storage arrangement. As David already pointed out, one can cluster {i, a} and {i, b} or partition {i, a, b} so that the physical arrangement is identical. If one clusters {i, a} and {i, b}, then the cost of the join is zero. And if one partitions {i, a, b}, then the cost of no join at all is the same as the cost of joining {i, a} and {i, b}. Idiot.

[further irrelevancies snipped]

> You missed my point entirely. My point was that the physical models of
> 1 and 2 might as well be identical (accepting your comments about
> foreign keys, which are a logical issue). If the physical model is
> identical then there is no reason to suppose any difference in
> performance.

He's a self-aggrandizing ignorant. They are universally skilled at ducking points (and clues.)

>>The empty set does not contain a value; every non-empty set contains at
>>least one value.  Doesn't that imply that the empty set indicates the
>>absence of a value?

>
> The empty set IS a value. Whether the empty set implies something or
> not depends on the interpretation the user puts on any proposition
> containing the empty set. It is still a value.
>
>

>>Use something similar to the empty set instead of SQL NULL.  It would
>>completely eliminate 3VL altogether.
>>
>>Some operators:
>>
>>Ø = Ø        is TRUE
>>x > Ø         is TRUE unless x = Ø or x = +infinity
>>x < Ø         is TRUE unless x = Ø or x = -infinity
>>x + Ø = x        use the empty sum (0)
>>x * Ø = x        use the empty product (1)

>
> So Ø looks like some value of the domain in question. If all you are
> proposing is better domain support then I agree. Support for
> user-defined domains and operators is a far better alternative to
> nulls. Unfortunately the task of defining sensible results for such a
> value for every operator could be onerous. For that reason I think the
> technique of decomposition into separate relations still has its place.

I would not let the idiot off the hook quite so easily.

 >>x > Ø         is TRUE unless x = Ø or x = +infinity
 >>x < Ø         is TRUE unless x = Ø or x = -infinity

So, if x is of a domain that is a total order, the additional 'value' renders it not an order at all. That's a loss that is not easy to accept.

 >>x + Ø = x        use the empty sum (0)
 >>x * Ø = x        use the empty product (1)

Since when has voodoo mathematics ever benefited anyone? Consider:

(x + 1) * (Ø + 1)
= (x + 1) * (1)
= (x + 1)

(x + 1) * (Ø + 1)

= (x + 1) * Ø + (x + 1) * 1
= (x + 1) + (x + 1)
= 2 * (x + 1)

How many C-level executives do you know who will accept a number that might be a billion dollars or might be two billion? (I mean other than at Enron.) Received on Wed Oct 04 2006 - 07:50:52 CDT