Re: boolean datatype ... wtf?

From: Tony Andrews <tony.andrews.1_at_gmail.com>
Date: Thu, 30 Sep 2010 03:32:58 -0700 (PDT)
Message-ID: <c0d584e9-3395-47d6-96f2-539c515bc72b_at_n3g2000yqb.googlegroups.com>



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. A pretty common "real world" example in my experience would be where we have to design a database to record data gleaned from the public via a paper or web-based form with lots of "checkbox" questions - e.g. for a car insurance application:

[ ] Is the car kept in a locked garage overnight?
[ ] Does the car have an immobiliser fitted
[ ] Have you made a claim in the past 3 years
... and so on for dozens of questions to which the business needs to know just the Boolean answer.

We could again introduce a lot of specific domains like garaged_status ('GARAGED','NOT GARAGED'), but I'm not sure what would be gained by that. 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! Received on Thu Sep 30 2010 - 05:32:58 CDT

Original text of this message