Re: Implementation of boolean types.
From: John <no_at_email>
Date: Thu, 14 Jul 2005 14:22:59 +0100
Message-ID: <42d66730$0$24455$db0fefd9_at_news.zen.co.uk>
>
>
> What would we need UNKNOWN for when we already have NULL? NULL is all
> we have to mean both "inapplicable" and "missing/unknown" for all other
> data types in SQL, so why not for BOOLEAN? The differences seem rather
> subtle to me:
>
> UNKNOWN - we know that we don't know whether this is true or false
> NULL - we don't know whether we know whether this is true or false?!
>
> My head is spinning...
>
Date: Thu, 14 Jul 2005 14:22:59 +0100
Message-ID: <42d66730$0$24455$db0fefd9_at_news.zen.co.uk>
Tony Andrews wrote:
> Jonathan Leffler wrote:
>
>>-CELKO- wrote: >> >>>SQL deliberately left out Booleans [...] >> >>SQL-1999 and SQL-2003 both have a BOOLEAN type, with recognized values >>TRUE, FALSE and UNKNOWN. I'm not clear whether NULL is equivalent to >>UNKNOWN or not; I've not scrutinized the weasel-words carefully enough.
>
>
> What would we need UNKNOWN for when we already have NULL? NULL is all
> we have to mean both "inapplicable" and "missing/unknown" for all other
> data types in SQL, so why not for BOOLEAN? The differences seem rather
> subtle to me:
>
> UNKNOWN - we know that we don't know whether this is true or false
> NULL - we don't know whether we know whether this is true or false?!
>
> My head is spinning...
>
Consider a table that holds the shoe size of 3 entities. Me (John), George Bush and my keyboard.
Description | Shoe Size
-------------+------------
John | 10 UK George Bush | unknown My Keyboard | null
So we can see that null and unknown mean different things. George has a shoe size, but I don't know it, wheras my keyboard doesn't have a shoe size.
Having said that, I believe that NULLs are a bad thing, and would never use them. (The example above could be normalised away by separating it into 2 tables with no "shoe size" entry for "My Keyboard".
John Received on Thu Jul 14 2005 - 15:22:59 CEST