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

Alexandr Savinov wrote:
>
> The first question: Is this design (4 tables) right price for having no
> nulls? Do nulls deserve such an urgly design?
>

I'll ignore this one because it's entirely subjective as well as irrelevant.

> The second question:

[snip]
> - determining object type (i.e., to what table it has to be added in
> 4-table design) is equivalent to determining if it may have nulls in the
> 1-table design.
>

Yes, and constraints to check this are I assume part of the data model in either case. How we handle constraint / type violations is implementation-defined. It's not a model issue.

> The third question: Has the 4-table design less information? Obviously,
> no. It has 4 times more tables that are expensive resource.

You are confusing logical and physical models again. The point of the data model is to separate the two. Relvars (NOT the same thing as tables) are not an expensive resource because cost is implementation-defined. Nothing in RM says these 4 relvars must be implemented as separate data structures. Possibly it is desirable to implement them as a single data structure but that does not change the data model at all - they are exposed in the data model as separate relations. This is the heart of what RM is about.

> These tables
> have to be linked somehow because these objects are not isolated and an
> object from one table represet an entity from another table. In other
> words, each entity is distributed among many tables and we need to keep
> track of them via links. So we add additional columns. But why we then
> tried to remove null columns if then we add even more auxiliary columns?
>

Nothing in your hypothetical problem suggests it is necessary to "link the tables" whatever that means (there are no "links" in RM)

> You simply follow some dogma and do not want to think yourself. In many
> cases it is really desirable to try to avoid nulls. In other cases they
> can be tolerated. It is always a trade off. What I wanted to say is that
>

Trade off implies you get some benefit in return for the complexity, compromises and errors that nulls create. I don't see that here. Nulls are used in today's databases because we use SQL or similar systems that demand them - not because of any intrinsic merits.

-- 
David Portas 
SQL Server MVP 
--