Re: boolean datatype ... wtf?

From: Erwin <e.smout_at_myonline.be>
Date: Thu, 30 Sep 2010 04:47:04 -0700 (PDT)
Message-ID: <cc88409d-c1e2-4951-8ce5-fd74cfbd79c8_at_a9g2000yqg.googlegroups.com>



On 30 sep, 08:03, David BL <davi..._at_iinet.net.au> wrote:
>
> What if I want to record a base relation like the following?

Then I'm tempted to suggest that you are resorting to theoretical artifice for which, while not invalid per se, it will be extremely hard to find a compelling practical case where such base relations are needed. (pls note that what triggered the discussion here, was a blog entry by VT commenting on some other discussion that was very clearly rooted in 'practical applications'.)

> a  b  c  d
> ----------
> F  F  F  F
> F  F  T  T
> F  T  F  T
> T  F  F  F
> T  F  T  T
>
> These boolean attributes can't be eliminated in the manner you
> suggest.
>
> On another note, I can easily imagine applications with boolean
> attributes that cannot be regarded as derived or calculated from other
> information recorded in the database.  E.g. soft cover versus hard
> cover, read versus unread, fiction versus non-fiction for a book.
>
> I agree that one typically has the option of using more relvars to
> record these attributes instead as the presence/absence of some
> tuple.  However I think it won't be possible when these boolean
> attributes form part of the primary key.

That is correct, but that is also where my question for a compelling case comes in.

> I can imagine applications
> where we don't have convenient and simple identifiers for entities,
> and they end up being uniquely identified by a large number of
> attributes, and I would have thought there could easily be cases where
> some of the attributes in the key are boolean.

Well, if that really is "easy" then you can easily provide a compelling case.

Booleans in relations mean that the external predicate for that relation must contain constructs such as "it is <boolattr> that ...". Meaning specifically that there might be tuples that say that "it is false that ...".

Booleans inside a candidate key means that a natural language formulation for the identifier represented by that key, is something like "the class of things for which it is <boolattr> that ...", e.g., "the class of things for which it is true that they are male", and "the class of things for which it is false that they are male".

Does that strike you as a very sensible idea ? I say it smells like excessive circumlocution, baked into the database itself. Received on Thu Sep 30 2010 - 06:47:04 CDT

Original text of this message