Re: All hail Neo!

Gene Wirchenko wrote:
> 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.

> 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.

> 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. This is a much more comprehensive approach (a better guardrail, if you will) than any query tweaking you might propose.

All the control and guardrails, etc., you are asking for, are in the DDL. The determination of whether to allow missing data is statically made; there's no reason to wait until runtime for the system to start complaining.

Marshall Received on Thu Apr 27 2006 - 01:32:40 CEST