Re: Does Codd's view of a relational database differ from that ofDate & Darwin? [M.Gittens]

In article <42a811ed_at_news.fhg.de>, savinov_at_host.com says...
> > The empty set is equal to itself, and it has a type---set (loosely
> > speaking). Is NULL equal to itself? (It is not in SQL.) What is its
> > type?
>
> I would prefer not to distinguish NULL and empty set because I do not
> find enough reasons for that.

Yet I have distinguished them for you. I am trying to be a little bit formal here. Isn't your response here tantamount to "I don't want to think about it. It makes sense if you squint a little and don't think too hard"?

> And I would prefer NULL to be untyped.

Yet the empty set, which you claim it is equivalent to, is obviously a set. Caveat: I like strong typing; it colours my thinking.

> It is a variable that may have a type while NULL is a value that can
> be assigned to any variable of any type including relvars.

Values also have types. NULL is not a value. It is not equal to itself. Or do you claim that it is?

> There might be the following situations where we would like to
> distinguish between
>
> - a single-valued variable having no value assigned (NULL), for example,
> Price=NULL, and
> - a set-valued variable having no set assigned (empty set), for example,
> Children={}, and
> - a query returning empty result set, for example, SELECT * FROM Orders
> WHERE date='01.01.2001'
> - a query or other operation returning an error
>
> The reasons for having such a distinction might be
> 1. theoretical, and
> 2. practical
>
> From practical point of view it is clear: we always have things to be
> more informative and therefore we overload the existing values
> (including NULL) with additional inappropriate meaning, for example,
> NULL as an error, or try to inroduce new special values like empty set,
> empty salary, salary is not yet computed etc.

I am not sure what you are arguing here. Do you suggest that all cases of empty sets, error conditions, empty relations and missing/inapplicable information should be mushed up into a single concept, and they should not be distinguished?

> But it would be very interesting to know what fundamental reasons might
> exist for separating NULL as a variable value and empty set as a
> collection without elements. For example, do we really need to have
> different meaning for:
> 1. some_relvar = NULL, and
> 2. some_relvar = {}
>
> How do you think? What is the fundamental difference between these two
> lines of code and do we loose a lot if we retain only the first one
> (with the meaning of the second)?

#2 has a clearly defined meaning. What does #1 mean?

-- 
Jon