Re: Proposal: 6NF

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.

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

-- 
David Portas