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

From: Alexandr Savinov <spam_at_conceptoriented.com>
Date: Fri, 18 Nov 2005 10:23:06 +0100
Message-ID: <437d9d8b$1_at_news.fhg.de>


Gene Wirchenko schrieb:
> On Thu, 17 Nov 2005 17:00:23 +0100, Alexandr Savinov
> <spam_at_conceptoriented.com> wrote:
>
> [snip]
>
>

>>>An RDBMS as a set of know facts. If I have dogs with
>>>and without colour then I have at least two relvars one with and one
>>>without a colour attribute. If I need to distinguish between colourless
>>>dogs and dogs of which I don't know the colour then I add an attribute
>>>to indicate that fact. I don't need to add a null.
>>
>>Sometimes you need. For example, if you are not allowed to create more 
>>tables. Such design can be more or less attractive but nothing changes 

>
>
> Why do you use such an inflexible system?

I think the system where we create one table for each type of entity (one table for normal dogs and one separate table for colourless dogs) is really inflexible. Assume how many attributes dogs may have and do you propose for each such dog type to create one table with appropriate attributes? I think it is much better to create several tables for main dog types and the same time to allow for null values in some cases.

But again. The question is not in choosing a good design. The question was about the semantics of nulls, that is, what does it means when we have nulls. Choosing good design (with many or a little of tables is another question - it almost always an art. And I completely agree that having a huge number of null values is not a good idea. But what is even worse, these null values are frequently are not controlled, i.e., they are used inappropriately.

-- 
http://conceptoriented.com
Received on Fri Nov 18 2005 - 10:23:06 CET

Original text of this message