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

Alexandr Savinov wrote:
> 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.
>

When you say that both methods are equivalent you are ignoring an absolutely crucial point about nulls - that they are not values. That is, they don't have some fundamental and important properties that we require other values to have. For this reason, using nulls is NOT equivalent to some other system for representing missing data if that other system uses values and values alone. In particular, if you allow nulls you will have to modify your system of types and evaluation rules in order to support nulls as "special" data (data that is not a value). This is the reason that nulls violate the Information Principle in RM.

Coping with special data has major implications for your data model. It is precisely because of the complexity of solving this problem that values are preferred to nulls.

At any rate, I think you have acknowledged that nulls are an optional feature. We can ALWAYS model ALL information without them, including information about missing data.

-- 
David Portas 
SQL Server MVP 
--