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

"Marshall Spight" <marshall.spight_at_gmail.com> wrote in message news:1132297015.048512.100940_at_g44g2000cwa.googlegroups.com...

> As to the specific issue at hand, I want to assert in the strongest
> possible terms that the issue isn't about what NULL "is" or isn't.
> We may define our formal systems to have whatever semantics
> we wish. We may come up with better or worse abstractions,
> but whatever we do, it won't be a perfect reflection of the
> "Real World(tm)" so we should drop the whole "is" business and
> simply talk about what's useful.
>

The above is true in the abstract, but the SQL standard defines NULL as a token indicating a missing value.
One is free to disregard standards, but that doesn't make them cease to exist.

> Having some kind of representation for missing values is
> not a requirement for a data model, but many people happen
> to find it useful.

And one of them is Ed Codd. One of Codd's 12 rules is that a relational DBMS must have a systematic treatment of missign values. That's only one man's opinion, but it's a pretty important one.

>Having a representation for an unknown
> value is not a requirement for a data model, and I have
> heard almost no one argue that it is a useful thing to have.

>
> My thinking is that a good design would include a principled
> way of handling missing values, and would exclude any
> special handling of unknown values.
>
> The question also arises as to what exactly SQL's null "is."

Again, the curious incident of the dog in the night.

> Is it unknown or empty? The answer, alas, is that it depends
> on the context, a disastrously bad state of affairs. If you have
> a table with a nullable int column and two rows, one null, and
> you select sum(column) from table, you'll see that the nulls are
> treated as empty. If you have a row with two int columns, one
> null, and you select column1 + column2, you'll see that null
> is treated as unknown. This is simply bad design, and not
> any kind of indictment of relational theory.
>

If you take NULL as meaning "no opinion", per our previous discussion, it makes perfect sense.

eval ( NULL + 43) = NULL.

> As far as my take on "SQL vs. PICK", it seems about as
> likely to provoke rational debate as the Cal vs. Stanford
> football game, (a notorious local long-running rivalry.)
> I'm sick of the whole "vs." part. What I find interesting is
> asking, what did SQL get right, and what did it get wrong?
> I am also interested to consider what Pick got right and
> what it got wrong. Lots of interesting meat for discussion
> there, and perhaps not quite so confrontational.
>

Agreed.

I'm still waiting for a thumbnail sketch of the Pick data model / programming environment, to see what it might have gotten right and what it might have gotten wrong. Received on Fri Nov 18 2005 - 09:12:44 CET