Re: boolean datatype ... wtf?
Erwin wrote:
> On 1 okt, 02:24, Brian <br..._at_selzer-software.com> wrote:
>
>>On Sep 30, 3:22 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>>
>>>Paul Mansour wrote:
>>>
>>>>On Sep 30, 11:17 am, Tegiri Nenashi <tegirinena..._at_gmail.com> wrote:
>>
>>>>>On Sep 30, 3:32 am, Tony Andrews <tony.andrew..._at_gmail.com> wrote:
>>
>>>>>>create table applications_with_immobolisers (application_id
>>>>>>references applications primary key);
>>>>>>... etc.
>>
>>>>>>That may be the right approach in a theoretical true RDBMS, but I'm
>>>>>>pretty sure it would get me sacked as a lunatic in any SQL-based DBMS
>>>>>>team!
>>
>>>>>Ah, this is why one don't usually find any unary relation in SQL Dbms!
>>>>>This is very odd from theoretical perspective as one might expect
>>>>>there are many more unary relations than binary ones, many more binary
>>>>>than ternary and so on (akin to Zipfian distribution). Well SQL made
>>>>>creating a table more expensive than adding an column, that is one of
>>>>>its many implementational sins.
>>
>>>>Isn't creating a new table conceptually more expensive than adding a
>>>>column, regardless of the implementation? Perhaps this is why Date's
>>>>well-known supplier and parts database has a S.STATUS column rather
>>>>than a STATUS table, and P.COLOR column column rather than P.COLOR
>>>>table, and all the attendent foreign keys.
>>
>>>Concepts are free.
>>
>>>If one uses 6NF for temporal data, little difference exists between
>>>creating a new table or adding a column.
>>
>>Ignorance or irresponsibility?
>>
>>Is Badour exhibiting his complete ignorance to the consequences of
>>decomposing a 5NF database scheme into one that is in 6NF? Unless the
>>5NF scheme was already in 6NF, the equivalent 6NF scheme will contain
>>numerous additional cyclical referential constraints that were not
>>present in the 5NF scheme. Assuming that the introduction of the
>>additional attribute doesn't violate 5NF, no additional constraints
>>are required that aren't implied by the candidate key constraint on
>>the 5NF relation scheme. Introducing a 6NF relation scheme to the
>>equivalent 6NF database scheme requires explicit declaration of a
>>cyclical referential constraint. If it isn't just plain ignorance,
>>then doesn't such careless disregard of those consequences border on
>>irresponsibility? People here have the impression that Badour knows
>>what he's talking about. Deliberately or carelessly misleading those
>>who look up to them is behaviour usually attributible to politicians
>>and lawyers, con-men and thieves--predatory personalities.
>
> Explain "cyclical referential constraint".
>
> And explain "additional attribute".
As a general observation, lower normal forms imply dependencies that
"equivalent" higher normal forms do not imply. In that sense, the higher
normal form is not really equivalent to the lower normal form. However,
in general, we choose the higher normal form precisely because the
dependencies implied by the lower normal form are invalid.
BS assumes going from 5NF to 6NF that the additional dependencies
implied by the 5NF design are valid and must be enforced, when the
designer may have chosen 6NF precisely because those dependencies are
invalid.
None of BS's BS does anything to address my observation that proper
support for 6NF demands a product where the addition of a table is no
more costly than the addition of a column.
Received on Fri Oct 01 2010 - 17:08:05 CEST
Original text of this message
