Re: boolean datatype ... wtf?

On Oct 4, 6:36 pm, Hugo Kornelis
<h..._at_perFact.REMOVETHIS.info.INVALID> wrote:
> 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

Here's another example for the null-haters. Suppose that P{A,B,C} is a table with key {A,B} that permits C to be null. To eliminate the null, it must first be determined whether there should be a value for C or not--in other words, is each NULL in column C an applicable NULL, or an inapplicable NULL. So now you have P1{A,B,D} where D is a boolean indicating whether there should be a value for C, and P2{A,B,C} where C cannot be NULL, and P2[AB] IN P1[AB]. If you also need to eliminate D, then you need P1{A,B}, P2{A,B} and P3{A,B,C}, with P2[AB] IN P1[AB] and P3[AB] IN P2[AB]. So if you disallow boolean types too, you would need three tables and two interrelational constraints to eliminate nulls from just one column! Moreover, the resulting schema may be in violation of POOD, since P1 and P2 have exactly the same heading!

Brian Received on Tue Oct 05 2010 - 23:06:21 CEST