Re: boolean datatype ... wtf?

From: Hugo Kornelis <hugo_at_perFact.REMOVETHIS.info.INVALID>
Date: Wed, 06 Oct 2010 13:43:43 +0200
Message-ID: <jinoa61d904ngceq5abm2u0cl2n6lc6usd_at_4ax.com>


On Wed, 6 Oct 2010 02:13:56 -0700 (PDT), Erwin wrote:

>On 6 okt, 09:02, Hugo Kornelis <h..._at_perFact.REMOVETHIS.info.INVALID>
>wrote:
>> Hi Keith,
>>
>> Interesting world you're living in, where users get to change the
>> application code.
>
>It must be understood that the "user" is the _DBMS_ user.
>
>That is, the person that you presumably call the "end user" ONLY in
>the case where that end user has direct interaction with the DBMS,
>through a query console or so.
>
>In the other cases, the DBMS user is the application developer writing
>the code of the programs that will be accessing the database.
>
>This notion is very clearly explained in the introductory chapters of
>"Introduction to Database Systems". 8th edition, but I suspect this
>is one of those pieces of text in the book that have been present ever
>since edition 1.

Apologies for the terminology mismaatch, then. In my world, the "user" is the one who uses an application. One who develops an application, I call (who boring) a "developer". This terminology mismatch supports my idea that many database developers tend to forget who they develop for. (And who pays their salary).
Too many ideas vented by database developers (and database development academics) focus on what's good for the database developer rather than what's good for the peron I call the "end user" (you forgot to tell me
how you call him or her). But let's not drift too far off-topic.

>> So thanks for making my point - you have given me yet another good
>> reason to endorse the inclusion of a boolean data type in databases.
>
>You are conflating "inclusion of booleans in databases (/database
>designs)" with "inclusion of booleans in data manipulation languages
>that access/interact with databases".
>
>I thought the initial subject was the former. You are debating the
>latter.

The initial subject was the former, and I think I presented lots of arguments for including boolean as a data type in databsae designs.

It is also my experience that most database implementations either allow the boolean datatype in DDL *and* allow boolean-valued expressions as predicates in queries, or disallow the boolean datatype in DDL *and* disallow boolean-valued expressions as predicates in queries.

But you are right, that connection is not necessary. It would be possible for an implementation to allow a user-defined function to return a boolean data type, yet not offer the option to use that same datatype in column declarations. (Though I would not like such an exception-ridden implementation - but again, let's not stray off-topic).

Best, Hugo Received on Wed Oct 06 2010 - 13:43:43 CEST

Original text of this message