Re: Does entity integrity imply entity identity?

From: Mr. Scott <>
Date: Thu, 6 Aug 2009 08:25:49 -0400
Message-ID: <>

"Walter Mitty" <> wrote in message news:97zem.877$
> "Mr. Scott" <> wrote in message
>> "paul c" <> wrote in message
>> news:M7sem.37833$Db2.32757_at_edtnps83...
>>> Mr. Scott wrote:
>>> ...;
>>>> If the requirement is to record in the database as much information as
>>>> is available, ...
>>> Imaginary requirements are rampant. Dattabases should record only the
>>> information that is necessary for their individual purposes. Everything
>>> else is wasted so-called econony. In most enterprises, the supposed
>>> purpose is usually fake.;
>> Are you trying to say that there should never be any missing information?
> In theory, there is no difference between theory and practice.
> In practice, there is.
> Every information system needs a way of marking the absence of data in a
> place where there might have been data. In some situations, there not
> only might have been data, but there should have been data. In other
> situations, a place for data has been created, but it is inapplicable to
> the situation.

"Inapplicable data" is an oxymoron, so it doesn't make sense to provide a place for it. A table that allows "inapplicable nulls" has a disjunctive predicate and should be split up into one base table for each disjunct.

> In an ideal world, information is never missing if it isn't supposed to be
> missing. In the real world, a system can be behave somewhat more robustly
> in the face of missing information if it has a systematic way of dealing
> with missing information. In a table, the number of places for data is
> always the product of the order and the cardinality. Depending on table
> composition, this can result in places for data where there is no data.
> SQL uses NULL to mark such an occurence. The behavior of the SQL
> evaluator in the face of NULLs is sometimes surprising, and less than
> ideal.
> I don't think I'm telling you anything you don't already know.
Received on Thu Aug 06 2009 - 14:25:49 CEST

Original text of this message