Re: So what's null then if it's not nothing?
- From: "David Cressey" <david.cressey@xxxxxxxxxxxxx>
- Date: Fri, 18 Nov 2005 08:12:44 GMT
"Marshall Spight" <marshall.spight@xxxxxxxxx> wrote in message
news:1132297015.048512.100940@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> 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.
.
- Follow-Ups:
- Re: So what's null then if it's not nothing?
- From: Marshall Spight
- Re: So what's null then if it's not nothing?
- References:
- So what's null then if it's not nothing?
- From: michael
- Re: So what's null then if it's not nothing?
- From: frosty
- Re: So what's null then if it's not nothing?
- From: michael
- Re: So what's null then if it's not nothing?
- From: Marshall Spight
- So what's null then if it's not nothing?
- Prev by Date: modeling disjoint subsets
- Next by Date: Re: So what's null then if it's not nothing?
- Previous by thread: Re: So what's null then if it's not nothing?
- Next by thread: Re: So what's null then if it's not nothing?
- Index(es):
Relevant Pages
|
