Re: The BOOLEAN data type

71062.1056_at_compuserve.com (--CELKO--) wrote in message news:<c0d87ec0.0303311011.2966d628_at_posting.google.com>...

> There were a few reason for not having it in SQL-92.
>
> To be a datatype in SQL, you have to be NULL-able. If you allow a
> LOGICAL datatype, then it has to be TRUE, FALSE, UNKNOWN and be
> NULL-able! But NULL does not work with AND, OR and NOT. Then there
> is the problem that an empty scalar subquery is cast as a NULL. The
> CHECK() constraint in the DDL accepts predicatres that test UNKNOWN,
> while ON and WHERE in the DML do not. It gets to be a mess really
> fast.

But the problems are on nulls, not on the boolean type.

> Aside from the destruction of the foundations of SQL, Booleans are
> usually, but not always, a sign of bad programming.

SQL is clearly bad founded and the boolean type is the most fundamental type of all.

If you do: select b from a where b = 0;

(b = 0) returns a boolean typed value.

SQL violates the orthogonality principle of the language design.

> Someone is
> storing the state of the database at one point in time as a flag. It
> is a computed column and we all know better than to store redundant
> data like that.

With SQL you can not have computed columns with the boolean type.

Regards Received on Tue Apr 01 2003 - 09:55:36 CEST