Re: Proposal: 6NF

Brian Selzer wrote:
> "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.
>>

So, let me get this straight: we round up all the NULLs, pack 'em together in Guantanamo Bay, and the world will be a better place?

>

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

How are two schemas - one "with NULLable attributes" and one "without" - equivalent?

   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.

What does SQL's OUTER JOIN have to do with what you described?

How does a description of COMPOSE make your point?

>
>

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