Re: boolean datatype ... wtf?

On Sep 30, 7:47 pm, Erwin <e.sm..._at_myonline.be> wrote:
> 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.

If you're saying it is statistically unlikely that you'll find examples then fair enough, but I thought you were saying something stronger than that.

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

Compelling... hmmm. Is plausible enough?

Example : I have the means to measure (x,y) in a cave but not z. I want to record pH measurements taken on every stalagmite or stalactite. Relation is

        pHLevels(x,y, isStalagmite,pH)

isStalagmite is part of the key.

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

So you're saying two valued enumerated types are ok, but boolean attributes are not.

I regard this as a matter of personal choice (or you could say style or syntax or religion). Obviously you could work either way and map between them easily enough. Since it can be cumbersome to define enums and think of "neutral" attribute names I'm not going to agree with you that boolean attributes should be universally outlawed purely on the basis that enums are more descriptive or map more reasonably to natural language. Received on Thu Sep 30 2010 - 15:41:29 CEST