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

In article <1134052281.291970.61920_at_g44g2000cwa.googlegroups.com>, boston103_at_hotmail.com says...
> > > What you'd like to store is say a (person, location) pair (or tuple,
> > > does not matter). You'd want to deal with a domain of strings,
> > > extended by two markers, UNKNOWN and MISSING to represent an address.
> >
> > What are you talking about now? This has nothing to do with my example.
>
> That has a whole lot to do with yours or similar examples.

I never mentioned locations or addresses.

> Instead of
> storing precomputed truth values/judgements, one should arguably
> rather store actual facts.

I do. A person's opinion on whether Oslo is the capital of Honduras is a fact just like the person's last name is, if it is opinions we are interested in. I don't care what the capital actually *is*, at least not enough to put it in the database.

> You suggest to store:
>
> (person, opinion, veracity).

No, actually. I meant (person, opinion, ...) (if it were a binary relation we wouldn't need 'missing' NULLS), where the domain of 'opinion' is { TRUE, UNKNOWN, FALSE }.

> I suggest to store (person, opinion) where opinion is a set {opinion1,
> opinion2,..., UNKNOWN} and then derive veracity.

Of course it can be handled differently. I just don't see why my initial design should be disallowed.

> You probably do not
> need to handle MISSING which would be automatically handled by just not
> storing the fact.

Yes, one can always do this. I take for granted here that we want to (or are willing to) use 'missing' NULLs; otherwise, there is no use discussing NULLs, is there?

> > > > Codd says null=null is UNKNOWN. Either he is here redefining the notion
> > > > of equality,
> > >
> > > Yes, he does.
> >
> > I don't think so. What would be the point of that? Where is this kind of
> > equality ever used in the RM? I think he is saying that null=null is
> > UNKNOWN in the context of a restriction, like a WHERE-clause in SQL.
>
> Sorry, but saying null=null evaluates to UNKNOWN is already a
> redefinition of the equality predicate.

... unless he by '=' means equivalence!

> You do not need to take anybody's word for that. It's rather an
> obvious statement. Take for example De Morgan laws or any other
> logical expression transformation. Saying that two such expressions
> are *logically equivalent* means (by definition) that they have the
> *same* truth tables. Now, with your suggested approach to redefine
> equality for truth values,

I don't suggest to redefine equality for anything. I don't think Codd does either.

> one would never be able to determine if two
> truth tables are in fact *the same* as some attempts at such comparison
> would produce UNKNOWN should any row of such table contain UNKNOWN or
> some such.

Fair enough. And this doesn't mean that arithmetic has "ceased to exist" in SQL due to a redefinition of equality of numbers, because arithmetic doesn't depend on comparing truth tables?

> > Fascinating. How does this make any difference? If you would like to
> > enlighten me, please tell me what '=' signifies when you compare two
> > logical expressions in a WHERE clause in SQL.
>
> I might be able to tell if say what you mean by "compare two logical
> expressions in a WHERE clause in SQL".

What's so unclear about it? The very same examples I have used several times earlier. "select * from Foo where (a < 16) = (b > 7)" if a and b are numbers; "select * from Bar where a = not b" if a and b are truth values.

> >Or in a restriction in the
> > RM, to be more technology independent.
>
> For example ?

A relational algebra or calculus expression---but we have to use a textual language anyway, so it doesn't really matter.

-- 
Jon