Re: Proposal: 6NF

"David Portas" <REMOVE_BEFORE_REPLYING_dportas_at_acm.org> wrote in message news:1159882356.495737.117850_at_i42g2000cwa.googlegroups.com...
>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. A loop join
>> would require a scan or an index seek for each row (presumably in the
>> table
>> with the smaller cardinality). A merge join would require that {i, a}
>> and
>> {i, b} be presorted or sorted on the fly--provided, of course, that the
>> domain for i has a partial order defined on it. A hash join would
>> require
>> either (1) that a hash index be maintained, or (2) that a hash be
>> computed
>> on the fly during a scan. None of this extra computation would be
>> required
>> for {i, a, b}. I would argue then that your statement is only true if
>> {i,
>> a} and {i, b} are presorted (as is the case when a clustered index is
>> defined in Sql Server), or if the cardinalities of {i, a} or {i, b} or
>> both
>> are small.
>
>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.
>

I agree. If the physical models are identical, then the performance would be similar. But common sense argues against the idea that the physical models should be identical. If {i, a, b} and {i, a}, {i, b} are equivalent, then since i, a and b are of the same types, it would take at least 1/3 extra storage in separate tables because each i would occur twice.

>
>> 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 agree that decomposition into separate relations still has its place. I just don't think that nulls should be dismissed arbitrarily.

After further consideration (prompted by Bob's harangue), I think that the results of some of the operators enumerated above are not sensible. Ø does not belong to any numeric domain, and you can't add apples and oranges, but on the other hand, there is only one empty set, so Ø = Ø should be TRUE.

>--
>David Portas
Received on Fri Oct 06 2006 - 10:32:13 CEST