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_at_newssvr11.news.prodigy.com>
> So why did you object that I was depending on a "physical order" of
> tables?
> 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.
>
> 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.
>
Date: Mon, 02 Oct 2006 09:26:29 GMT
Message-ID: <9X4Ug.875$NE6.138_at_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.
>
> Roy
>
Received on Mon Oct 02 2006 - 11:26:29 CEST