Re: boolean datatype ... wtf?

From: Erwin <e.smout_at_myonline.be>
Date: Wed, 6 Oct 2010 06:29:45 -0700 (PDT)
Message-ID: <a10b5823-8d2e-4174-a95b-8ec4a7676881_at_j5g2000yqh.googlegroups.com>


On 6 okt, 13:50, Hugo Kornelis <h..._at_perFact.REMOVETHIS.info.INVALID> wrote:

> Probably. But I guess Brian kind of lost me when he wrote that a single
> nullable column has to be replaced by not one but two seperate tables in
> a null-less design.

In lots of situations where nulls show up in a design, the reality is that "missing" information may be "genuinely unknown" (e.g. natural person is known to have a professional occupation, but which profession that is, happens to be unknown), or it may be "inapplicable" (e.g. natural person is known to be unemployed, i.e. is known to not have any professional occupation at all). Or take religious belief: "known to have one, but unknown which one it is", versus "known to not have one".

It's explored in more depth in "How to handle missing information without using nulls" on www.thethirdmanifesto.com, and in "Database Explorations", chpt 23. If you have only a single separate relvar for the "null" case, AND it is the case that "inapplicable" applies, then the predicate of that separate table must be a disjunction, such that in the end, if a tuple appears in that table, you still don't _really_ know what that tuple means. Received on Wed Oct 06 2010 - 15:29:45 CEST

Original text of this message