Re: 3 value logic. Why is SQL so special?

Chris Lim wrote:

> Roy Hann wrote:
>

>>It's worse than that.  Suppose one user can't be bothered to find out if the
>>customer is insolvent and another user decides the null means insolvency or
>>otherwise isn't a relevant attribute.

Then why have I had to spend so much time in my career explaining to reasonably intelligent people why their queries returned the wrong answer?

  It's certainly easier (when
> writing queries) to deal with NULLs than to handle separate tables for
> every optional attribute,

I must insist you back up that statement quantitatively and qualitatively. It is far easier to deal with two names than with surprisingly inconsistent semantics for the same reason it is far easier to deal with a compile-time error than a run-time error.

  which is the proposed solution (considering
> how many NULLs there are in a 'typical' database, the number of extra
> tables is enormous).

So? All a table is is a variable name. Do you likewise suggest programmers use the same name for all variables in their programs?

> This is one argument where the theory just does not seem to have a
> case, at least until SQL supports a better way of combining all the
> optional attributes of an entity together to make querying easier.

SQL never will, which is ultimately why SQL is irrelevant.

  I
> mean, with the whole surrogate key vs natural key debate I can see both
> sides to the argument, and even though I wouldn't do it personally, I
> can see how a database with purely natural keys could work.

If you can see two sides to the same thing, you don't have a clue what you are talking about. A natural key is nothing more or less than a familiar surrogate.

  But a
> database without NULLs? It might be theorectically correct, but it
> would be a nightmare to write queries against.

I disagree. My personal experience dealing with scores of intelligent database users suggests that NULL is the nightmare. Received on Tue Sep 19 2006 - 06:23:49 CEST