Re: boolean datatype ... wtf?
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Thu, 30 Sep 2010 16:22:37 -0300
Message-ID: <4ca4e371$0$14832$9a566e8b_at_news.aliant.net>
>>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.
Date: Thu, 30 Sep 2010 16:22:37 -0300
Message-ID: <4ca4e371$0$14832$9a566e8b_at_news.aliant.net>
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. Received on Thu Sep 30 2010 - 21:22:37 CEST