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

From: Alexandr Savinov <spam_at_conceptoriented.com>
Date: Fri, 18 Nov 2005 16:17:53 +0100
Message-ID: <437df0b2$1@news.fhg.de>

Gene Wirchenko schrieb:
> On Thu, 17 Nov 2005 16:47:53 +0100, Alexandr Savinov
> <spam_at_conceptoriented.com> wrote:
>
>

>>JOG schrieb:
>>
>>>Alexandr Savinov wrote:
>>>
>>>
>>>>What people cannot understand is that we cannot simply disable nulls. It
>>>>is too simplistic point of view. It is not possible to say that we will
>>>>not use nulls and that is all. Why? Because the notion of absence exists
>>>>in almost any data model. We need to know if an object exists or not. If
>>>>yes, then we get some value. If not then we get null.

>
>
> No, if not, we get another value.

No, it is not a value - it is an absence of value. Ok, if you like to refer to absence of thing as thing then why not. But I find it somehow misleading. Because if something is absent then it is already not a thing (call it vacuum if you want). It is important only how this "value" behaves and what are its operational characteristics.

>>>"absence exists in almost any data model?" That makes no sense to my
>>>ears. If you don't know something why try to type it in as a fact
>>>(outside some logistical efficiency considerations)?. 
>>
>>Because sometimes we have a slot for that and we must write some value 
>>into it.

>
>
> You keep harping about flexibility. Why do you not use a system
> that does not force you to fill in unnecessary slots?

These unnecessary slots need not be filled in because initially they are nulls. If we do not specify a value for an entity then it can be also assumed to be null. Another reason is that even if we need to do it then it can be automated. The thirds reason is that it is not clear what is more difficult: to fill in "unnecessary" slots or to insert a huge number of "unnecessary" link records in intermediate tables and auxiliary columns. It is always a trade off. So I think that 1. using null values, and
2. using intermediate link records
are things of the same level. These mechanisms are *both* of crucial importance and in some sense they serve the same purpose. The difference is only in physical packing. In the first case we write null value in slots while in the second case we use intermediate link records (non-primitive entities which reflect the existence). If we are setting non-null value to an attribute then in the second case it is equivalent to inserting one (or more for more complex relationships) link record. If we set to null some attribute then in the second case it is equivalent to deleting some link records.

It is not possible to choose between these two mechanisms between normally we are somewhere in between. Using many tables with many auxiliary intermediate tables and columns is also "bad" just like using too many nullable columns.

-- 
http://conceptoriented.com

Received on Fri Nov 18 2005 - 09:17:53 CST