Re: boolean datatype ... wtf?

From: Erwin <>
Date: Sat, 2 Oct 2010 06:18:33 -0700 (PDT)
Message-ID: <>

On 2 okt, 13:52, Paul Mansour <> wrote:
> On Oct 2, 5:41 am, Hugo Kornelis
> <> wrote:
> > On Fri, 1 Oct 2010 07:51:37 -0700 (PDT), Paul Mansour wrote:
> > >Erwin, suppose then that we do want to explicity take "unknown" into
> > >account with two checkboxes as you say, or I think better yet, with
> > >three mutually exclusive radio buttons, to explicity specifiy  Yes,
> > >No, and Unknown or Male,Female and Unkown, or what have you. How then
> > >would you model this? Is this a column  with three allowable values,
> > >or a column with two values where no corresponding row indicates the
> > >third option? Alternatively, there could be just two radio buttons
> > >indicating, say, Male and Female, and neither one is pre-selected, so
> > >it is clear whether or not the question was answered. Same question,
> > >how is this then modeled?  I think Tony Andrews has a good question,
> > >and it's more fundamental than the GUI.
> > The most logical choices, IMO, are:
> > 1) A nullable column with two possible values. Whether boolean or
> > CHAR(n) and a CHECK constraint for the legal values is immaterial; any
> > column with two possible values is basically a boolean in disguise
> > (except that the DBMS doesn't hand you the algebraic operations on a
> > platter, you have to explicitly code the ones you need).
> > 2) For the NULL haters, that same column (but now not nullable) in a
> > seperate table, so you can avoid the NULL by omitting the row there.
> > (And of course, the NULL haters who also don't like extra tables will
> > simply add a third value to the CHECK constraint and add the extra logic
> > in their queries to make that third value act like NULL, so they can
> > think that they have avoided the issue by simply renaming it).
> > Best, Hugo
> This is how I thought it would be done. And I wouldn't have thought it
> would be controversial.
> You write above that “any column with two possible values is basically
> a boolean in disguise”.  Contrast this a  comment by Erwin above.
> Erwin writes about Gene’s post that in Genes’s case, his Boolean
> “really isn't just a Boolean”.

If you abstract away all the differences, then after that everything is the same.

Being a two-valued type does not suffice to be a boolean.

Stating things like " 'x implies y' is equivalent to 'not y implies not x' " is sensible if x and y are truth-valued, but not if x and y are, say, gender-valued.

CAN one model gender as a boolean ? Of course one can. Is it also a good idea ? I don't think so. It's circumlocution to say "it is false that z is a man".

CAN one include booleans in base relvars ? Of course one can. Is it also a good idea ? I don't think so. It's circumlocution to say, within a proposition represented by the tuple in which the boolean appears, "and it is the case/not the case that ...".

I think that if such circumlocution is built into the database structure, then the expressions we need to write to manipulate the data will expose such circumlocution too.

I don't think I said something else anywhere in this thread. Received on Sat Oct 02 2010 - 15:18:33 CEST

Original text of this message