Re: Practical considerations of dealing with two meanings of NULLs

From: Marshall <marshall.spight_at_gmail.com>
Date: Wed, 08 Aug 2007 16:38:50 -0000
Message-ID: <1186591130.276890.160320_at_m37g2000prh.googlegroups.com>


On Aug 8, 3:58 am, "sinister" <sinis..._at_nospam.invalid> wrote:
> One simplistic method of trying to distinguish multiple meanings possibly
> associated with NULL is to associate particular non-NULL meanings with those
> values.
>
> For example, I might want to store both "unknown" and "known, but not yet
> filled in by data entry clerk." I could associate NULL to one and a
> particular non-NULL value to the other, or non-NULL values to both.
>
> If the data at issue are e.g. strings or something categorical, this is OK.
> (The only problem I can think of is the case where (in the interface---I'm
> using a webserver for that) I give users a selectbox of predetermined
> choices, and there's an associated textbox where they can put in "Other"
> (non-predetermined values)---what's to stop them from overlooking the
> predetermined choice "Unknown" and typing in "don't know" in the textbox?)
>
> But if the data are numerical, it's messy. It's easy if the data are known
> to be nonnegative, because then one can reserve particular nonnegative
> values for this (e.g. "-1 means not filled in by user," "-2 means known").
> But this method just seems ugly and kludgey to me.
>
> Is there any clean method of dealing with this?

My take is that missing information or what have you is application specific. I notice that the various examples you describe are all closely associated with specific applications. Note how it would be impossible to try to divorce those examples from their specific application.

The whole thing is also made more difficult by the lack of union types. Both C and SQL lack union types. (OOPLs such as C++ and Java may be said to support union types in the form of classes, but this is a bit of a stretch from the usual meaning.) If you have proper union types, it is easier to simply specify the specific alternatives possible without running into combinations that don't mean anything.

(Using multiple relations with a shared key can achieve the same thing. I wonder if this could be dealt with via some merely syntactic mechanism?)

Marshall Received on Wed Aug 08 2007 - 18:38:50 CEST

Original text of this message