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

Alexandr Savinov wrote:
> mAsterdam schrieb:

>> Alexandr Savinov wrote:
>>> Jon Heggland schrieb:
>>>>> 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. In particular, it does not make sense to 
>>> ask if two things that do not exist are equal or not. 
>>
>> Yet it is a syntactically correct question to ask in any query language.
>> Let me rephrase: while it is true that it makes no sense, there is
>> no formal reason why it shouldn't.

IOW NULL doesn't fit in with typed variables.

> If
> there is such an assignment (a mark) for some entity then effectively
> all comparisons have to be avoided.

Ok.

> In particular, a good query language
> should be built in such a way that such "bad" comparisons" are not
> necessary (because they lead to problems).

Avoiding problems in a language design makes other, lower level languages a necessity.
You never know what you throw away with it when you throw away the possibility to express a problematic concept.

> Yet, if some query language
> or other mechanism implies or provokes such "bad" comparisons then I
> think that it is a bad approach (of course, only if we interpret NULL as
> absence). Or, it is a low-level approach that simply provides access to
> database implementation specific features. (Just like C++ provokes for
> hacking by using pointer arithmetics.)
>
> One approach to data retreival that does not brings about such "bad"
> comparisons is based projection and de-projection operations. We see
> data items as entities that exist in multidimensional hierarchical
> space.

A table is as dimensional as it's number of columns. What benefits do we get from the hierarchies?

> Then we can ask a question how this set of data items looks from
> another perspective. If we go higher to a more general perspective

Higher in this case is more aggragate. Not more abstract ('general').

> then
> we apply operation of projection. If go lower to a more specific
> perspective then we apply de-projection. More complex queries may use
> zig-zag form.

?

> One nice cosequence is that the problem with nulls does not appear at
> all, it does not exist (the NULL problem is NULL).

How is that a consequence?

> More specific approach that could be used as a correction of existing
> query languages consists in using a kind of REMOVE or DELETE keyword
> instead of assignment SomeVariable=NULL, for example,

Somewhere you lost me, I don't know where exactly (so I interjected some remarks above).

> myObject.removeAlong(SomeVariable)
> myObject.deleteFrom(SomeVariable)
> etc.
>
> Such a convention is much more meaningful because NULL has more to do
> with existence/non-existence (creationi/deletion) then with assignment
> and comparison. Assignment of normal value could be then written as
> follows:
>
> myObject.createAlongAs(SomeVariable, "NormalValue")
> myObject.addToAs(SomeVariable, "NormalValue")
> etc.
>
> Here we add this object to the specified axes with the specified
> concrete coordinate.
>
Received on Fri Nov 25 2005 - 18:38:19 CET