Re: So what's null then if it's not nothing?

Jon Heggland wrote:
> ...
>
> Still, the simple notion of equality has been given up in all other
> domains if you consider NULLs values. Why not instead twist the
> definitions slightly so that NULL is not a value, but the name for a
> special state for a variable? If I had my way, "NULL" wouldn't be a
> valid expression. We would just have IS_NULL() and SET_NULL(), and NULL
> as such couldn't possibly show up in a truth table or literal
> expression.
 > ...

In a perverted sort of way, this makes sense, except for the name "NULL". Mountain Man achieved some notoriety lately - he was quoted outside of here as saying about nulls something like "they're everywhere, they're everywhere!". Like the new-agers who believe everyting and anything is possible.

Forgetting about apps for a moment, in most real systems, one level below the user, the typical db engine, one could say that basically there are only three kinds of results supported, loosely, 'yes', 'no' and 'error'.

For example, 'error' might be the result when a query mentions an attribute that doesn't exist.

It seems the null proponents want a fourth result, 'maybe'. When a system produces the answer 'error', I think most people expect it to stop. Letting 'maybe' answers persist and propagate without stopping seems the same as letting the system continue after an 'error' result and letting it input 'error' to further operations.

For me, the more intriguing question is whether a system can avoid the 'error' result, eg., is there a logical interpretation that would let a system return 'false' instead of 'error' when a query mentions an attribute that doesn't exist. If there is, then maybe we can achieve some economy in our implementations, eg., a lot fewer error messages! Loosely, is a two-result db system logically possible and would it remain useful?

cheers,
pc Received on Fri Dec 16 2005 - 17:26:09 CET