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

Alexandr Savinov wrote:
> David Portas schrieb:
> > Alexandr Savinov wrote:
> >
> >>>Not at all the same thing because nulls violate the Information
> >>>Principle, which is a foundation of RM. Nulls as formulated in SQL also
> >>>create logical problems that are very hard to solve - at least SQL
> >>>hasn't succeeded in solving them very satisfactorily.
> >>
> >>Maybe, so what do you propose?
> >
> >
> > In place of SQL? The Relational Model would be nice to have one day...
> > :-)
> >
> >
> >>>RM does not prohibit such questions. If it is more natural to give some
> >>>answer then the user can demand such an answer. The user can decide
> >>>what he wants to see in the case of a dog with colour or a dog without
> >>>colour. I would challenge your implication that users find nulls"more
> >>>natural". I bet most DBMS users wouldn't do a very good job of
> >>>explaining what a null is. In fact in many database projects the
> >>>developers go to a lot of trouble to hide nulls from regular users.
> >>
> >>User and developers are not part of a data model.
> >>
> >
> >
> > Neither are the questions. Your point was that certain questions were
> > forbidden in the absence of nulls. Mine was that users decide on the
> > questions and that null isn't an answer that they want or need.
> >
> >
> >>and the same because effectively it will not be visible. Why do we need
> >>to mark things/facts as absent by means of nulls if we can simply delete
> >>them physically? Because things exist in multidimensional hierarchical
> >>space so they exhibit themselves in a more complex manner than
> >>exist/non-exist. And of course it is differs from what RM teaches.
> >>
> >
> >
> > Can you give an example of how nulls could exhibit information
> > information that is somehow "more complex" than can be represented
> > without them? This is somewhat more important than your earlier
> > assertions that nulls are merely "convenient". If you think nulls are
> > _necessary_ to represent certain types of information then you ought to
> > be able to demonstrate that by example. It seems plain to me that no
> > such example can exist (unless you contrive some data model that is
> > very stunted in the types of information it can represent - certainly
> > not RM which represents multidimensional information very well).
>
> Here is an example. Our problem domain consists of a set of objects
> which can be characterized by a set of attributes. This set of objects
> is rather generic and the expert we are interviewing says that there
> well may be objects for which any attribute does not make sense.
>
> Then we want to produce correct reports with aggregated information. If
> we use nulls for inappropriate attributes then the database will (if
> implemented so) produce correct reports.
>
> Do you have an alternative to this design without nulls?
>

You described your problem domain but you didn't mention any data model. Assuming you want to use RM you could represent each type of object with a distinct set of attributes as a distinct relvar. No nulls would be required.

Are ALL the attributes optional? Then apparently you may have some objects that contain no information. Arguably you can represent those with a relvar with zero attributes (which is permissable in RM) although I don't think that's especially useful here. Presumably you might like to know how many such objects you have, so add an attribute to count them.

> Ok, since the depate is over I will just summarize the positions:
>
> 1. "We tolerate nulls, we don't like them." That is, nulls are necessary
> evil. We should avoid using them becasue it is the source of many
> problems. (Reformulate me if I am not correct, because it is not my
> position.)
>

NO. Definitely not *necessary*. They are used in some current database products but are not essential to represent information in an RDBMS.

> 2. Null is one of the most important initial notions and many other
> notions can be derived from it. The mechanisms and constructs for
> manipulating and maintaining nulls are of crucial importance. Although
> we can avoid using nulls this will be a significant limitation both from
> theoretical and practical points of views.

>From a *practical* point of view only (possibly - given the constraints
of many of today's systems). Not from a *theoretical* one.

-- 
David Portas 
SQL Server MVP 
--