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

In article <1133798068.172086.7660_at_g44g2000cwa.googlegroups.com>, boston103_at_hotmail.com says...
>
> > > Sorry, one cannot get more specific than defining truth table as
> > > that's the only way to describe what the logical operations mean.
> >
> > Of course one can. One can define the truth table for equivalence, for
> > one thing!
>
> So what ? What substance does equivalence as a logical connective add
> to the game ? It's just another truth table, that's all.

Now you really boggle my mind. One minute, you claim that truth tables are the end all, be all desideratum for Codd's meaning; the other, you say they don't have any substance!

AND, OR and NOT is not sufficient to infer or define equivalence in 3VL.

> >Or one can say "Despite using the same symbol w for both the
> > unknown truth value and 'value at present unknown' nulls, and saying
> > they should be treated uniformly, we treat them differently."
>
> Supplying truth tables carries much more weight that the vague words

No, the three truth tables carry no weight at all with regard to equivalence. You can *assume* that he uses the same definition / truth table for equivalence as Lukasiewicz, but the text suggests otherwise, and he does not provide the missing truth table.

> "they should be treated uniformly" because the latter begs the question
> "what do you mean by 'uniformly' ?" whilst the former does not.

No, *your* interpretation begs the question "what do you mean by 'uniformly'?". My interpretation does not.

> > > > And it seems a curious omission indeed. TTM considers boolean the *only*
> > > > datatype/domain that *must* be supported.
> > >
> > > I imagine that TTM just does not need unknown because it uses the 2vl.
> >
> > That's not my point. The point is that a DBMS should support a truth
> > value datatype.
>
> I am not sure, as I said before, that the data type is so terribly
> important for storing data. TTM does not provide any rationale for the
> must-be-supported data type.

Constraints depend on truth values. The restrict operator depends on truth values. You cannot define the relational model without truth values.

> > You have a SQL table with a (3VL) boolean column. You want to put NULL
> > (UNKNOWN) into one row, and NULL (missing) into another.
>
> Forgetting for a moment about you bizzare insistence on calling a
> non-Boolean value Boolean,

Then suggest another name you'd prefer I use. I've asked you for such a name three or four times. I'll call it Lukasiewiczian, if you don't come up with anything easier to type.

> if I were to store a 3VL constant I would
> just do so regardless of what's it called NULL, UNKNOWN, 1/2, or
> something entirely different.

"Just do so", as if by magic? Please. If NULL is used both as 'missing' and as a normal value for a data type, how do you formulate your DML statement?

> > > > I'd agree if Codd hadn't used the same symbol for reasons of uniform
> > > > treatment.
> > >
> > > "Uniform" is indeed an unfortunate word here.
> >
> > What do *you* think it means?
>
> I have no clue.

But you are certain it does not mean what I think it means? Why, if you have no better alternative?

> > No. He doesn't define equivalence;
>
> So what ? It's enough to define a *single* truth table, say, for
> AND, and it would have been clear that the strings he uses {true,
> false, w} are indeed logical constants.

Irrelevant. They may be logical constants, but that has no bearing at all on whether or not he uses the conventional 3VL equivalence relation. In fact, as I may have said before, the text suggests that he doesn't.

> > AND, OR and NOT is not sufficient. He
> > could very well have envisioned an equivalence truth table where w<->w
> > is w, not T.
>
> He surely could, but it would be a strange thing to do as it would be
> a departure from the 2VL tradition.

3VL tradition, you mean. (Is logic just a matter of tradition, by the way?). I'd say it's already a departure from tradition that x = x is not (necessarily) true.

> It's unclear what use such connective might have.

No, it's very clear. "Truth values can be stored in databases and we want the treatment of all unknown or null values to be uniform."

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

> > For the exact same reason that we don't call zero NULL for the integer
> > domain.
>
> 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.

> >Come on, you should substantiate your claims.
>
> A very simple example, integer 3 and 4 are not the same as rational 3
> and 4 for obvious reasons, and yet using the same name for both does
> not cause any confusion. Why using NULL as logical constant and NULL
> as 'missing value' should present a problem ?

Your example is disingenuous. Integer 3 is not the same as 'missing', so using the same name for both *would* cause confusion.

Does "SET SomeAttribute = NULL" mean setting it missing, or setting it to a "logical constant"? (Or the empty string, or zero, depending on the declared type of SomeAttribute.)

-- 
Jon