Re: boolean datatype ... wtf?

On Fri, 1 Oct 2010 15:24:34 -0700 (PDT), Erwin <e.smout_at_myonline.be> wrote:

>On 1 okt, 23:29, Gene Wirchenko <ge..._at_ocis.net> wrote:
>>
>>      I do not want the exponential explosion if I have customers with
>> boolean attributes.  In my client billing system, there are two:
>> whether the client billing is PDF only and whether they pay by credit
>> card transaction where we process a payment after a delay if we have
>> not heard otherwise.
>>
>>      Why would I want to split the client table into four tables?
>>
>> [snip]

>OK. I admit that on the sheer face of it, your argument seems right.
>
>But I propose we get a look _beyond_ the "face of it".

     In your proposal below, you have neglected to tell me why I should split the client table into four tables.

     If I have to split the client table, I have to rewrite a lot of other programs. If I split again, I get to do it again. Is there some benefit to this? I do not see it.

>If you speak about "whether client billing is PDF only", you are
>already suggesting that "client billing" really isn't just a boolean.
>In particular, you are suggesting that there really are other billing
>modes than "PDF", and that there may exist clients who want "PDF +
>postal mail", that there are other clients who want "postal mail
>only", and (for the humorous part of it) "no billing at all".

     Ah, no. There are semantics that you do not realise.

     All clients billing generates PDFs. We keep an archive of them for internal use. If a client wants to be billed only by PDF, then we do not print anything on paper. If he does not, then we do. There are only two choices.

>I propose you consider a design with a relvar that simply records
>"client wants PDF billing", another one that records "client wants
>postal mail billing", a constraint "client must express at least one
>billing mode".

     It does not happen. If it did, I would make a change. Actually, since this is a client billing system, we would probably bill for that.

>With such a design, if newly arising technology allows for "novel
>billing modes", then all you have to do to your database is add
>another relvar, plus include that relvar in the union that is part of
>the constraint.

     So what?

     I will also have to implement the use of the "newly arising technology". That will probably be far more complex than a simple table structure change.

>Similar observations apply to "customer's preferred mode of payment".

     Ditto with me.

>When I was a "young Turk" in IT land, I formulated my own design
>principle : "codes are poor, entities are rich". What I meant by that
>is that "A boolean is a piece of 'codified' information, and therefore
>it doesn't convey much information after all. A separate entity (ER
>terminology, relational equivalent being 'a separate relvar' holding
>particular tuples) allows for specifying WHY that boolean piece of
>information happens to be true.".

     In these cases, call it whim. The system need not concern itself with why.

>IOW: if a boolean is true, then somewhere deeper down inside, _THERE
>IS ALWAYS A REASON WHY_, and _KNOWING_ that 'reason why' is _ALWAYS
>MORE AND BETTER_ than just 'knowing that it is so'.

     Not in this case. The system can not derive the value itself.

>Oh, and I am very much aware of the case where legislation does not
>allow you to actually be 'aware' of 'the reason why'.

     Not applicable here.

     This is a mature application. Great changes in the way that things are done are rather unlikely. If my boss says that the frog can only jump one of two ways, I will use a boolean. If the frog gets more dextrous in the future, I will deal with it then. Our frogs must be slackers, because I do not have to do this very often. My congratulations on the success of your frog-breeding program.

Sincerely,

Gene Wirchenko Received on Mon Oct 04 2010 - 23:49:44 CEST