Re: All hail Neo!
Date: Thu, 27 Apr 2006 01:34:22 GMT
Message-ID: <ycV3g.66413$VV4.1271134_at_ursa-nb00s0.nbnet.nb.ca>
>>On 26 Apr 2006 15:30:06 -0700, "Marshall Spight" >><marshall.spight_at_gmail.com> wrote: >> >>>It is worth noting that this is a *design* issue and >>>not a theoretical one per se. >> >> For example, C will quite happily do integer calculations that >>cause overflow and not indicate any sort of error. (The result is >>undefined.) That makes it less useful and is one reason why I do not >>use it much. >> >> In the database arena, I want to know when my data is not up to >>snuff, just as I prefer seeing "Division by zero error" to getting >>nonsense output.
>
> If, by "not up to snuff", you mean possibly-missing, then you can tell
> if this is possible statically by looking at whether the schema so
> specifies. If the schema does allow it, you must write code to
> account for the possiblity.
Where are your HCI results confirming that users of dbmses take these steps? I can assure you they do not take them.
>>I would prefer to have guardrails. >>To me, "That operation is invalid because..." is better than a >>questionable answer. I can then correct the error and try again.
>
> And what are you going to correct it to? You're going to
> rewrite the query to have the semantics that I'm proposing:
> " ... where not null". It is better to just do that in the first place.
Sometimes, it will be "where A is not null". Other, times it will be "where A is not null and B is not null". Other times, it will be "Oh, I have to find out what those values are." Still other times, it will be "I don't really care about the aggragate. I am much more interested in these instances where the value is unknown."
It is not better to just assume the user wanted something unspecified and to prevent the user from ever expressing what they really want. This is an endeavor that requires thought. Elixirs intended to avoid thought, like null, do harm and no good.
>>How fast do you want your wrong answers?
>
> If you are defining any operation on a less-than-fully-filled-in
> dataset as "wrong", then declare your schema to forbid
> missing data.
With all due respect, doing so would be wrong in the examples I already cited. The company knows the customer filled out a questionnaire, for instance, and left the field blank. This is entirely different from the situation where the customer has never seen the questionnaire.
Tossing out a million questionnaires because single women living alone don't like to advertise that fact would be stupid beyond belief. Almost as stupid as directing your mailings to young adult males to advertise a product that appeals mostly to middle-aged women.
You pretend that the idiot who chooses to allow nulls will anticipate every use of the data and will know that the behaviour of null is appropriate. However, nobody has such perfect knowledge of the future and the behaviour of null contradicts itself.
Stop being so stupid. You can do better. Received on Thu Apr 27 2006 - 03:34:22 CEST