Re: Practical considerations of dealing with two meanings of NULLs

On Aug 8, 9:38 am, Marshall <marshall.spi..._at_gmail.com> wrote:
> 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

C has a union type. It still needs a discriminant, though. So would any equivalent in the relational model, I think. OO systems like Java do a much better job of dealing with variations of this sort than simple unions. In effect the discriminant has been baked into the system. The problem would still remain that somehow you'd have to surface the distinct instances in a view. With relational views, you must have all the same columns for each row in the set, and this implies that you're stuck with nulls for the inapplicable ones for each row. Received on Sat Aug 11 2007 - 02:41:46 CEST