Re: Proposal: 6NF

From: Brian Selzer <>
Date: Fri, 13 Oct 2006 00:51:27 GMT
Message-ID: <jqBXg.14502$>

"Hugo Kornelis" <> wrote in message
> On Wed, 11 Oct 2006 10:01:20 GMT, Brian Selzer wrote:
>>"David Portas" <> wrote in message
>>> Brian Selzer wrote:
>>>> 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.
>>> That is pure speculation. When I said identical I meant precisely that.
>>> The only difference is in the metadata. There is no reason at all to
>>> store any values of i twice. Why should there be? If it is the same key
>>> value of the same type then it seems perfectly sensible to store it
>>> only once regardless of how many relations it appears in.
>>Regardless of whether you store the actual value or a pointer to a value,
>>the storage required would be at least 1/3 more, because either you have
>>three values or pointers per tuple or four values or pointers per pair of
>>corresponding tuples. There is no speculation involved, just simple
> Hi Brian,
> You're overlooking something. In an RDBMS, physical storage is seperated
> from logical model. If {i, a, b} is equivalent to {i, a}, {i, b}, then
> the storage engine could choose to use the exact same physical model for
> both logical models. Hence no difference at all in storage requirements.
>>> If you want to speculate some more then consider that only two bits of
>>> metadata may need to be added per tuple, which is presumably exactly
>>> the same as would be used to support nullable columns.
>>I'm not sure I follow. By two bits of metadata, do you mean two pointers?
> The storage engine must store, somehow and somewhere, how the physical
> representation chosen maps to the logical model requested by the
> designer. That information is metadata. And since it's stored on a
> "per-table" rather than a "per-row" level, the exact amount of metadata
> is completely irrelevant when compared to the amount of bytes used for
> storing the user data.
> Best, Hugo

Thank you for pointing that out, Hugo. Somehow I got it stuck in my mind that the physical organization mirrored the logical organization, which depends on the implementation.

Brian Received on Fri Oct 13 2006 - 02:51:27 CEST

Original text of this message