Re: The BOOLEAN data type
From: Costin Cozianu <c_cozianu_at_hotmail.com>
Date: Tue, 01 Apr 2003 18:55:02 -0800
Message-ID: <b6dj3g$41m9f$1_at_ID-152540.news.dfncis.de>
>
> type has.
> Are all the following values allowed?:
>
> true
> false
> unknown
> null
>
> Does null equal unknown? <<
>
> No, NULL is not the same as UNKNOWN and zero is not the same the empty
> string. But you understand why it was left out.
>
> 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.
>
> What we did give you was a predicate "<search condition> IS [NOT]
> [TRUE | FALSE | UNKNOWN]" so you could test for things.
>
> Aside from the destruction of the foundations of SQL, Booleans are
> usually, but not always, a sign of bad programming. 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.
Date: Tue, 01 Apr 2003 18:55:02 -0800
Message-ID: <b6dj3g$41m9f$1_at_ID-152540.news.dfncis.de>
--CELKO-- wrote:
>>>>_When_ it's implemented, it's not clear to me which domain the
>
> type has.
> Are all the following values allowed?:
>
> true
> false
> unknown
> null
>
> Does null equal unknown? <<
>
> No, NULL is not the same as UNKNOWN and zero is not the same the empty
> string. But you understand why it was left out.
>
> 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.
>
> What we did give you was a predicate "<search condition> IS [NOT]
> [TRUE | FALSE | UNKNOWN]" so you could test for things.
>
> Aside from the destruction of the foundations of SQL, Booleans are
> usually, but not always, a sign of bad programming. 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.
That's news to me :) First it's news that SQL had foundations. If it was
founded on relational model, than not only a boolean data type would be
unharmful, but would be almost mandatory.
Aside from the above quibble, it's socking news to me that booleans are
sign of bad programming. On the contrary, lack of booleans is a sign of
bad programming, and lack of support for boolean data type is a sign of
bad language design.
You should really go read up on good old Dijsktra, he knew a few things
about programming ...
Google for EWD1284