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

So let's see. In your database the user's code changes from

   where R.is_natural_person = true
to

   where R.is_natural_person = true

ie no change. And in the "other database it changes from

   where R.person_type = natural
to

   where R.person_type = natural

wow, yeah, I see what you mean. That is a huge difference! Not. For real man, enumerated types are a tried and true model that people find makes code /better/ not worse than only bools.

By the way, the evaluation of whether a commercial mailing should be sent should be encapsulated into a predicate function. So in a /good/ design a client would write neither of the above. Instead they would write

   where sendCommericialMailing(R)

and sendCommericialMailing is simple to implement in both models.

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

They are not interested in whether they are "private person" (why are you changing terms?). They are interested in whether they need to send a commercial mailing. Furthermore, when their world expands they will be interested in meeting new requirements. That is going to be easier with the enumerated type.

KHD Received on Wed Oct 06 2010 - 00:33:46 CEST