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

David Cressey wrote:
> "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.

Just so. What I was trying to deflect was not the idea that SQL's null has well defined semantics. I *does* have well-defined semantics; I just don't happen to like the definition. Rather, I was trying to avoid any conversation about whether this-or-that semantics for null (independent of SQL per se) was "right." There is no "right"; there are only qualities like usefulness or consistency.

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

I don't see how it makes perfect sense. Rather, it just strikes me as bluntly inconsistent. Why does summation behave one way "vertically" and a different way "horizontally?" I consider this inconsistency bad design. Vertically you get the "empty" semantics; horizontally you get the "unknown" semantics.

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

Yeah, that would be cool. We have had a few Pick advocates come through here, and while they have raised some interesting points, I haven't been able to construct a clear model of their system from their posts. I've never been able to find good reading about the topic, either.

Marshall Received on Fri Nov 18 2005 - 16:54:05 CET