Re: boolean datatype ... wtf?

On Tue, 5 Oct 2010 15:33:46 -0700 (PDT), Keith H Duggar wrote:

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

Hi Keith,

Interesting world you're living in, where users get to change the application code. Do you then let your database developers research whether each customer who is not a natural person is a company, charity or government and enter that information in the database?

>For real man, enumerated types are a tried and true model that
>people find makes code /better/ not worse than only bools.

No disagreement here - in cases where several types are relevant to the business, so that an enumeration makes sense.

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

Not really. The code above would work in a database that supports the boolean data type; other databases would throw a syntax error; you'd have to code around the limitation imposed by the missing data type by having the function return (e.g.) a CHAR(1) value, and then change the predicate to

  WHERE sendCommercialMailing(R) = 'T'

So thanks for making my point - you have given me yet another good reason to endorse the inclusion of a boolean data type in databases.

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

Sorry for the shift in terms from "natural person" to "private person"; English is not my first language. I had to google some terms to write that post, and while writing I accidentally switched 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.

Yes, you are right. Requirements may change. Who knows, maybe next year management will decide that income, shoe size, or eye color will be relevant for deciding who to send a commercial mailing. Meeting those new requirements will be much easier when those attributes are already in the database. Sure, it's a bit more work for the tens or hundreds of employees who actually USE the database to enter data of new customers, and it'll be some more maintenance of the application code, but that is only a small price to pay for the savings when management does decide to add shoe size as a deciding factor for mailings.

Sounds silly to you? I sure hope so!
But what exactly is the difference between the above scenario, and havng end users find out and enter "company / charity / government" if the business is only interested in whether a customer is a natural person or not?

Best, Hugo Received on Wed Oct 06 2010 - 09:02:34 CEST