Re: Multiple specification of constraints

From: Tony <andrewst_at_onetel.net.uk>
Date: 3 Mar 2004 07:28:05 -0800
Message-ID: <c0e3f26e.0403030728.8691f83_at_posting.google.com>


"Marshall Spight" <mspight_at_dnai.com> wrote in message news:<ivg1c.169860$uV3.728400_at_attbi_s51>...
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c225fl$rob$1_at_news.netins.net...
> > > If I enter my Date
> > > of Birth as 01-Jan-1972 (which it isn't), there is no conceivable
> > > constraint that will say "Error: lying about your age! And I know you
> > > are a Taurus!"
> >
> > Yes -- and that shows that data type constraints are but one aspect of data
> > integrity.
>
> I might point out a terminology issue here. In general, I have not seen
> the word "integrity" (in a data management context) used to describe
> the issue of whether the data matches what it is supposed to match
> in the outside world. The word is used only to refer to the internal
> consistency of the data.
>
> The larger problem you mention, getting the external predicate
> and the internal predicate to be linked in some way, is insoluable,
> and so we don't talk about it too much.

Quite. Even the most integrated system can't prevent a programmer from putting prompt A next to input field B, unless field prompts are forced to be equal to the underlying column name and cannot be modified, like DATE_SKULL_FRAC instead of "Date of Skull Fracture".

So, because database consraints can't prevent this situation that nothing can prevent, Dawn calls them flawed. Hmm... Received on Wed Mar 03 2004 - 16:28:05 CET

Original text of this message