Re: Proposal: 6NF

From: Brian Selzer <brian_at_selzer-software.com>
Date: Mon, 02 Oct 2006 09:26:29 GMT
Message-ID: <9X4Ug.875$NE6.138@newssvr11.news.prodigy.com>

"Roy Hann" <specially_at_processed.almost.meat> wrote in message news:ybudneB2QvzfRYLYRVnytQ_at_pipex.net...
> "Brian Selzer" <brian_at_selzer-software.com> wrote in message
> news:85QTg.6549$TV3.5203_at_newssvr21.news.prodigy.com...

>>
>> "Roy Hann" <specially_at_processed.almost.meat> wrote in message 
>> news:P-Sdnd58Trp7GYLYnZ2dnUVZ8tGdnZ2d_at_pipex.net...
>>> "David Portas" <REMOVE_BEFORE_REPLYING_dportas_at_acm.org> wrote in message 
>>> news:1159692483.421785.264660_at_c28g2000cwb.googlegroups.com...
>>>> Brian Selzer wrote:
>>>>>
>>>>> The argument JOG made focused only on recording information, not 
>>>>> retrieving
>>>>> it.  Why would anyone abandon a sound mechanism that can significantly
>>>>> reduce the computing capacity required to answer a query?
>>>>
>>>> Because your argument is merely an assumption based on what some
>>>> systems of today are capable of.
>>>
>>> It's worse.  His entire position is based on not knowing even what some 
>>> of today's products are already capable of.  For example, he seems 
>>> unaware of the role of the optimizer.
>>
>> I understand fully the role of the optimizer.
>

> So why did you object that I was depending on a "physical order" of
> tables?

>
>> That's one of my points.  If you arbitrarily split a table with a 
>> nullable column, then you're robbing the optimizer of possible execution 
>> plans.
>

> There is no logical way to decide whether to represent information as a
> row, an attribute, or a relationship. I can choose anything that is
> sensible. Whatever I choose is going to eliminate some possible plans but
> it is also going to create others.

> And let me repeat: I am not speculating that my approach works. I use it
> routinely and it works very well. I therefore don't care what plans the
> optimizer never got to consider and nor should anyone else.
>

If it works for most of the queries being submitted, then go for it! I've often seen exactly the opposite happen, where splitting a table caused a few queries to scream while at the same time significantly degrading the performance of all the rest.

>> It may make sense to split a table, for example, removing non-key columns 
>> that are seldom used in queries into another table in order to boost the 
>> performance of all other queries. The point I'm trying to make is that 
>> the decision should not be arbitrary.
>

> What is arbitrary about saying that an attribute which doesn't apply to
> one type of fact must necessarily belong to another? It is the
> inescapable conclusion. To suggest the opposite is not only arbitrary, it
> is capricious, counterproductive, and misleading. If it weren't so
> tiresomely familiar it's bizarreness would be blindingly obvious.
>

I think you're making the assumption that an attribute doesn't apply if its value isn't known. That is not always true. It is often the case that not all of the information about something is received at the same time. The interval during which the first bit of information is received and the final bit may be sufficiently long that it makes sense to record parts of that information at different times rather than wait until all of the relevant information is available and then recording it en mass.

> Roy
>
Received on Mon Oct 02 2006 - 04:26:29 CDT