Re: Does entity integrity imply entity identity?

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


"Walter Mitty" <wamitty_at_verizon.net> wrote in message news:97zem.877$Jg.706_at_nwrddc01.gnilink.net...
>
> "Mr. Scott" <do_not_reply_at_noone.com> wrote in message
> news:-8qdnUH-_M2gGefXnZ2dnUVZ_h2dnZ2d_at_giganews.com...
>>
>> "paul c" <toledobythesea_at_oohay.ac> 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