Re: Proposal: 6NF

From: Brian Selzer <brian_at_selzer-software.com>
Date: Tue, 03 Oct 2006 04:08:00 GMT
Message-ID: <AmlUg.1197$NE6.723_at_newssvr11.news.prodigy.com>

"J M Davitt" <jdavitt_at_aeneas.net> wrote in message news:60iUg.3585$Cq3.515_at_tornado.ohiordc.rr.com...

> Brian Selzer wrote:

>> "Cimode" <cimode_at_hotmail.com> wrote in message
>> news:1159797534.237592.159150_at_e3g2000cwe.googlegroups.com...
>>
>>>Brian Selzer wrote:
>>>
>>>>"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. 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. 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.
>>>
>>>Consequences of NULL uses goes far above he simple problem of
>>>execution. It hinders performance at all levels (response time,
>>>concurrency) and introduces a very strong part of subjectivity in
>>>interpretation of data presented to users.
>>>
>>
>>
>> I don't agree. Judicious use of NULL can improve performance, response
>> time, and concurrency.

>
> A wrong answer isn't always better because it cost less.
>

But an incomplete answer may be better than nothing. For example, if you delay arresting a suspected terrorist until you have enough evidence to convict, you get 9/11; if you pick him up and then develop the evidence through interrogation, search and seizure, you may not get enough for a conviction, but you might prevent an attack.

>   In addition, when used correctly, no subjectivity is

>> introduced. For every database schema with NULLable attributes, there is
>> always an equivalent schema without.

>
> Well, being the god* you seem to be, I won't doubt
> that solely because you said so.
>
> * Genius of Design
>

I'm not sure I understand your point. Are you asking for proof that a schema with nullable attributes can always be transformed into one without, or are you trying to put me back in my place because you don't think I know what I'm talking about? It's obvious to me that an outer join of a set of restricted projections of a table with nullable columns is equivalent the the original table, provided that each projection does not allow nulls, that each projection includes at least one key and either a subset of the columns that allow nulls or a subset of the columns that don't, and that each column is represented in at least one of the projections.

>   Any subjectivity would therefore be

>> independent of the database schema. On the other hand, arbitrary or
>> incorrect use of NULL can cause all of the problems you describe.
>>
>>
>>>>>Roy.
>>>>>
>>>
>>
Received on Tue Oct 03 2006 - 06:08:00 CEST