Re: boolean datatype ... wtf?

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]
>
> Sincerely,
>
> Gene Wirchenko

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

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

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

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.

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

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

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

Oh, and I am very much aware of the case where legislation does not allow you to actually be 'aware' of 'the reason why'. Received on Sat Oct 02 2010 - 00:24:34 CEST