Re: Multiple specification of constraints

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:<c258v3$v9c$1_at_news.netins.net>...
> "Tony" <andrewst_at_onetel.net.uk> wrote in message
> news: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...
>
> It does seem that DBA's spend a lot of time trying to figure out how to
> prevent programmers from doing this or that. One or more software
> applications written with the teamwork of all participants addressing how to
> get the most integrity in the stored data seems like a less flawed strategy
> than having DBAs figure out how to block programmers who figure out how to
> get around the walls built by the DBA. I realize that not all projects
> sound like the latter, but I suspect many do.

Why would any rational, professional programmer WANT to get around data integrity rules enforced in the DBMS? If it is "because the rules are wrong", then clearly they need to be fixed. If we take the view that because the DBMS-enforced rules MIGHT be wrong in some cases, we should disperse the responsibility among the developers of one OR MORE applications, things can only get worse, surely. You have N points of failure instead of 1.

> Even though you cannot ensure that the data coming into a system is sound,
> if you take 100 software development teams and have them write applications
> to meet the same data requirements (no UI specified), there will be some
> variance in the quality of the data captured that is due to the way the
> applications were written, right? So, you cannot prevent garbage coming in,
> but you can encourage quality input.

You CAN prevent garbage getting into the DATABASE via DBMS-enforced integrity rules, as far as is feasible. For example, you CAN ensure that Date Of Birth is a valid DATE within some specified range. The only garbage that NOTHING can prevent is data that passes all possible validation rules and yet is in fact false - like entering my Date Of Birth as 01 Jan 1972 when in fact that is a lie. "Encourage" isn't good enough - "prevention" is exactly what is needed as far as possible. I should be prevented from entering my Date Of Birth as 01 Jan 1066, or as 3.14159. Received on Thu Mar 04 2004 - 11:51:22 CET