Re: boolean datatype ... wtf?
Date: Wed, 29 Sep 2010 05:48:49 -0700 (PDT)
Message-ID: <3cb332c4-ae45-418d-a1e1-250f42ca52e6_at_k10g2000yqa.googlegroups.com>
On 29 sep, 13:51, Paul Mansour <psmansour2..._at_yahoo.com> wrote:
>
> What is the problem with a Boolean data type?
> .
> It is fundamental - so fundamental that in TTM it is the only
> required scalar data type: “We require that at least one built-in
> scalar type be supported : Namely, type “Boolean” (BOOLEAN in Tutorial
> D”).
It is fundamental _FOR A COMPUTING LANGUAGE_ because that computing language might have a need for evaluating some expression that follows the 'IF' (or for evaluating a ternary operator of the style <xpr> ? result1 : result2).
It is, imo, _NOT_ fundamental in the context of actual database design. In fact, I think that the justifiable cases for including a BOOLEAN in an actual database design (not talking of derived relvars aka views) are few and far between, if existant at all. I think that is precisely what VT was talking of: the RM already has a way for representing truth information (as the presence/absence of some tuple in some relvar with some particular predicate), and as a consequence the type BOOLEAN (_WITHIN DATABASE RELVARS_) must be considered redundant and unnecessary.
That the relation type {} has the same cardinality as the set of 2VL truth values, and that therefore, when amended/augmented/provided with a proper set of operators, it is isomorphic to boolean algebra, seems all too obvious. Whether that can be exploited usefully in the design of a language that wants to eliminate true and false (as such, only to replace those with DEE and DUM), is a bit less obvious. Received on Wed Sep 29 2010 - 14:48:49 CEST
