Re: boolean datatype ... wtf?

On 30 sep, 12:32, Tony Andrews <tony.andrew..._at_gmail.com> wrote:
> On Sep 30, 7:03 am, David BL <davi..._at_iinet.net.au> wrote:
>
> > On another note, I can easily imagine applications with boolean
> > attributes that cannot be regarded as derived or calculated from other
> > information recorded in the database.  E.g. soft cover versus hard
> > cover, read versus unread, fiction versus non-fiction for a book.
>
> I am with you there, even though it could be argued that you could
> have cover_type='soft', status='read', classification='fiction' etc.
> instead.

If you have to include person gender in some database design, which would be your preferred option:
(a) a boolean to say "male Y/N", or
(b) something that more akin to the style "additional type GENDER with values [that mean] 'male' and 'female' " ?

> Or we could create a plethora of tables like:
>  create table applications_with_garages (application_id references
> applications primary key);
>  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!

If your SQL-based DBMS had proper physical data independence, then I am quite convinced your claim would be false.

(Allthough by now, SQL has existed so long that it would take quite some amount of time before the majority of data management people using SQL have their totally derailed and confused thinking completely straightened out ...) Received on Thu Sep 30 2010 - 14:04:45 CEST