Re: The BOOLEAN data type

"Bob Badour" <bbadour_at_golden.net> writes:

> Some requirements will suggest the use of a boolean and some will not.
> What's your point?

If I may interject, I think the point of the whole discussion hinges on the validity of the statement by Joe Celko (for whom I hold great respect) that storing boolean data in a database is always wrong.

Lots of more or less contrived examples have been given showing cases where booleans seem to be indicated or contra-indicated, but those are special cases. What I'd like to see, from those of you who know more about these things than I, is a discussion of the relative merits of boolean attributes (true/false/null) and text encodings (yes/no/null) in cases where either seems sufficient at first glance.

Can booleans, combined with basic logic operations and the predicate IS UNKNOWN, be acceptable in cases where derived data is never stored, and each data item is true, false or unknown (null)? Or are there problems with the evaluation logic of SQL that will kick you in the teeth when you least expect it? Should a text encoding of boolean values be yes/no/unknown and NOT NULL? Should booleans be NOT NULL?

I've been using booleans when that fits my data model. I've never experienced any problems with this. Looking at some schemas, I seem to always make them NOT NULL, and usually give them a DEFAULT value, so I may have avoided problems that would otherwise have taught me to avoid their use.

-tih

-- 
Tom Ivar Helbekkmo, Senior System Administrator, EUnet Norway
www.eunet.no  T: +47-22092958 M: +47-93013940 F: +47-22092901