Re: boolean datatype ... wtf?

Tony Andrews 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. 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.

No, the business doesn't want to know true or false.

It wants to know the nature of the insurance application. Some "business analyst" or other nitwit intervened between the customer and business to strip the meaningful information from the customers' response so that it can be interpreted only with reference to some secret decoder ring. That contributes nothing but cost, burden, mystery and confusion where there needed to be none of these things.

I have actually screamed out loud at seeing an unintelligible stream of numbers, codes, and flags where actual values would have been just as easy and so much better. What is this fetish for encoding and concealing?

> 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!

Now there's a badge of honour I can get behind!

-- 
Roy