Re: So what's null then if it's not nothing?
Date: Fri, 25 Nov 2005 18:38:19 +0100
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.
> My opinion is that the assignment SomeVariable=NULL is a low level
> mechanim used by the database system to denote some entity as
> non-existing along dimension SomeVariable. So it is not a value - it a
> mark for the field (a value assumes comparisons, operations etc.)
IOW NULL doesn't fit in with typed variables.
> there is such an assignment (a mark) for some entity then effectively
> all comparisons have to be avoided.
> 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
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').
> 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).
> 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
> myObject.createAlongAs(SomeVariable, "NormalValue")
> myObject.addToAs(SomeVariable, "NormalValue")
> Here we add this object to the specified axes with the specified
> concrete coordinate.
Received on Fri Nov 25 2005 - 18:38:19 CET