Re: boolean datatype ... wtf?
Date: Thu, 30 Sep 2010 03:32:58 -0700 (PDT)
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);
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
create table applications_with_immobolisers (application_id references applications primary key);
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 DBMSteam! Received on Thu Sep 30 2010 - 12:32:58 CEST