Re: boolean datatype ... wtf?

On Sat, 2 Oct 2010 06:18:33 -0700 (PDT), Erwin wrote:

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

Hi Erwin,

True. I have just acknowledged this in my reply to Paul.

>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 disagree. It is my conviction that a database should be modeled to store the information that a business needs - not less (of course), but also definitely not more. Designers in general and database designers in specific too often try to cram more in the database than the users really need and want.

Consider a company that sells to both natural persons and businesses. A lot of commercial mailings go to only the natural persons, so they need an attribute to store whether a customer is a natural person. I would choose a boolean attribute "is_natural_person". You would call that circumlocution and choose an attribute "person_type", with "natural person" or "business" as its domain.

But now the company finds a new market. Two more types of customers start buying - government and charity organisations. Mailings are still for natural persons only.
Your model changes: the domain for the "person_type" attribute gets two extra values. My model remains unchanged, as a customer still can only be or not be a natural person.
This domain change is of course only a minor change. The major change falls on the users' shoulders. Now, for all the customers that will never get commercial mailings, some user will have to find out if they are business, government or charity - in order to populate a column that was added for the sole purpose of these commercial mailings.

If all the users are interested in is whether it is or isn't true that a customer is a private person, then it is in no way circumlocution to represent this in the database with a boolean that represents just that and nothing else.

Best, Hugo Received on Tue Oct 05 2010 - 00:36:14 CEST