Re: Proposal: 6NF

"Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message news:M6OUg.80$cz.1594_at_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]

Not true. The cost of the join is not zero. There are trade-offs when choosing a physical design. Since i is duplicated, 33% more storage is needed for {i, a} and {i, b} than for {i, a, b}. So if you have 10,000,000 rows, and each i takes 4 bytes, then even if they're clustered, the join of {i, a} and {i, b} would require 160MB to be read instead of 120MB. And that doesn't even include the additional storage needed for index overhead. So by choosing to partition {i, a, b} you're stating that you're willing to accept at least a 33% decrease in performance. That just doesn't make any sense.

>
>
>> 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.)

I hadn't considered that. The presence of Ø throws a wrench into the distributive property. Hmm. I guess substituting a typed value for Ø is the wrong approach, but I think that x + Ø = Ø is also incorrect. Perhaps it would be better to just ignore Ø. Received on Fri Oct 06 2006 - 10:33:35 CEST