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

Alexandr Savinov wrote:

> Jon Heggland schrieb:
> > In article <1132798608.160942.270970_at_o13g2000cwo.googlegroups.com>,
> > michael_at_preece.net says...
> >
> >>If you have a text/string field and it can have an empty string what
> >>have you got? What is the value of the data? How does that value differ
> >>from "no value at all"? Question mark.
> >
> >
> > Are two variables/"fields" (of the same type) with "no value at all"
> > equal?
>
> The question does not make sense because we cannot talking about things
> that do not exist.

But we can talk about things that do exist as empty variables/"fields".

> In particular, it does not make sense to ask if two
> things that do not exist are equal or not.

But, of course two things that do exist as empty variables/"fields" are, very obviously, equal.

> Why not to ask then if two
> records that have not been created yet (or have been already deleted)
> are equal?

Because they are different to empty variables/"fields". They do not exist as variables/"fields", regardless of whether they might or might not be empty.

>
> The issue of comparison of nulls with normal values or with other nulls
> arose because inappropriate application of attribute-value approach.

No. It arose because the standard is badly worded. If it is interpreted to mean the *presence* of an empty variable/"field" then the "issue" would never have arisen.

> In
> particular, the standard reasoning is that if we see some attribute then
> it is necessary to have a facility to take its value and to compare with
> other values.

Which is an entirely natural piece of reasoning. A datum is a piece of information. It exists because it is something known. That which is not known cannot exist as data. It is ridiculous to store the "fact" that we don't know something.

> It is a consequence of a general assumption that:
>
> all objects have some coordinates along appropriate dimensions
>

The general assumption that everything, all objects if you like, must have some column and row, or x and y, coordinates is flawed.

> However, there is another (more general) principle:
>
> objects may exist in multidimensional space without the necessity to
> exist in (to be projected to) all axes.

I think it is safer to use the term "data" than "object". An object, by definition, must contain some data. It is, again, something known. This need to account for missing information only arises if there is a flaw in the model.

>
> Such a phenomenon does not exist in real world and this is why it is
> difficult to imagine it. If we take two axes X and Y (say, Colour and
> Weight) then normally any point in it has two concrete coordinates x and y:
>
> Y
> |
> y|------o
> | |
> |-------------> X
> x
> However, in data modelling (our assumption) objects are not necessarily
> have to possess all the coordinates. Most of objects are not projected
> to most of existing axes and are not visible from those perspectives.
> For example, an object o might have coordiante x but not y:
>
> Y
> |
> | o
> | |
> |-------------> X
> x
>
> The traditional approach is somewhat dogmatic: if such a coordinate is
> not assigned then we must assign some special value and then compare it
> with other values anyway.

The "crux" of the matter - with regard to SQL.

> This does not make sense. If an object does
> not exist along this coordiante then it does not exist, and that is all.
> We do not see it. And any database procedure does not see it. Because
> having a coordinate means to exist.

I'm close to complete agreement with you on this. Not sure about the last sentence though.

>
> For example, the following object:
>
> Y
> |
> | o
> |
> |-------------> X
>
> has no coordinates at all. So it is exists as an entity (has a reference
> or a primary key) but does not exhibit itself in any other way.
>

This is a little esoteric for me.

Best regards,
Mike. Received on Thu Nov 24 2005 - 22:42:51 CET