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

Jon Heggland wrote:
> In article <1133896860.912140.197720_at_f14g2000cwb.googlegroups.com>,
> boston103_at_hotmail.com says...
[...]
> > What has the '<->' connective got to do with the idea of storing
> > logical values in the database ?
>
> create table test ( a boolean, b boolean );
> select * from test where a = not b;
>
> '=' here obviously means equivalence, not equality.

Yes, that's a reasonable interpretation.

>
> > > > > It is strange to suggest that a DBMS should have the capability to store
> > > > > the result of the evaluation of a condition?!
> > > >
> > > > What utility storing "the result of the evaluation of a condition"
> > > > might have except leading to data redundancy ? Presumably, all the
> > > > true facts are already in the database.
> > >
> > > Orthogonality, completeness, simplicity, power.
> >
> > Please, elaborate on each of the those four words.
>
> You don't know what they mean? That does explain a few things.

Sure, I know what the words mean in a specific context, but throwing them around in a technical argument smells a bit of marketing talk.

>
> Consider this example:
>
> create table test2 ( a integer, b integer );
> select * from test2 where (a < 12) = (b > 15);
>
> This query is a syntax error in SQL, or at least in Oracle. You can
> reformulate the condition to an equivalent, syntactically allowed
> expression, but why should we have to?

Apparently, the language designer(s) decided that the demand for the built-in equivalence won't be stong enough. Besides, it's trivial to write a custom function in major SQL dialects that implements any of your favourite connectives missing from the vendor-supplied set, as it is equally trivial in any major PL. Can you name many PLs that support equivalence (biconditional) ?

> Do you know how hard (and
> embarrassing) it is to teach SQL, due to its lack of consistency,
> orthogonality and lack of adherence to simple language design
> guidelines? Do you know how hard it is to create a parser for SQL, for
> the same reasons? But this is a different discussion.
>
[...]

> > > > Not calling zero NULL is a matter of convention/tradition, nothing
> > > > else.
> > >
> > > And you don't see any problems at all if we called zero NULL in SQL? I
> > > am beginning to find it hard to take you seriously.
> >
> > That's your problem. You did not specify the context or in other
> > words did not mention that you wanted to use the word NULL *both* to
> > represent the integer 0 *and* to represent a missing value in the same
> > domain which is clearly impossible,
>
> Hey! This may actually have been enlightening. Let me try to summarise
> your position:
>
> 1. Logical values don't need to be stored in the database.

I do not see a compelling reason to, yes, but I'd be glad to be educated by my betters in case I am missing something.

> 2. If we nevertheless were to store 3VL logical values in a database, it
> makes sense to use NULL for UNKNOWN.

Not quite.

It makes sense to use any words you like to represent more truth degrees than just two. If you need more truth degrees (interpreted according to your needs), naturally, you have to use more truth values to represent those truth degrees. Additionally (or in the first place), you have to extend your various data domains with desired markers to represent missing, unknown, or some other values besides non-pathological values. The names for such markers may be the same as, or different from, the logical truth values. Also, you'd want to extend various predicates (e.g. equality, greater than, etc) so that they would accepte the new markers as arguments and produced truth values that make sense in your model.

Alternatively, you might not want anything of the kind and just do what Date and other relational purists suggest one should do.

> 3. Attributes of the type "(3VL) logical value" cannot be 'missing'
> NULL, only UNKNOWN NULL.

They can mean anything that makes sense in your model. In particular, if it makes sense, the 3VL NULL (or if you choose the name UNKNOWN) can represent the notion of undefined, senseless, contradictory, whatever you have in mind. By themselves, they represent nothing but a bunch of symbols and rules to combine them into WFFs.

[...]

> > and now you blame someone else for
> > your failure to comunicate what exacly you've meant.
>
> FWIW: You have also failed to communicate that you mean to forbid the
> usage of NULL for 'missing' when you use it for something else.

You've apparently misundestood me. What NULL or any other symbol means is irrelevant as long as they unambiguously denote things/ideas in various domains. So, you can choose to use NULL both to represent a a missing value in one domain and an unknown or undefined logical outcome in another domain. If it's confusing, then just use different symbols in order to avoid such confusion.

E.g. you might have a mini-integer set INT ={0,1,NULL} with the usual operations extended so that they could accept NULL. Also, you might have a 3VL domain L = {TRUE, FALSE, NULL} Also, you might have defined the equality or whatever predicate whose domain is INT and its co-domain is L. Now, obviously, INT.NULL is not the same as L.NULL, they have different rules of game and represent different notions (existing in you mind). If you find using NULL confusing in a situation like that, by all means, using different names, e.g. MISSING for the former and UNKNOWN for the latter.

>
> > If using the same name for different entities (3I vs. 3R) belonging to
> > different domains is OK in one case, why is it a problem in the other
> > ? NULL in Codd's 3VL does not denote a missing value, but rather a
> > logical constant, so there should be no confusion as long as one knows
> > in what context the name NULL is used.
>
> Very well, but that precludes the use of 'missing' NULL for "logical
> value" attributes.

See above.

> --
> Jon
Received on Thu Dec 08 2005 - 03:46:08 CET