Re: foundations of relational theory?

"Marshall Spight" <mspight_at_dnai.com> wrote in message news:UTnob.67286$Tr4.190739_at_attbi_s03... [Quoted] > "Bob Badour" <bbadour_at_golden.net> wrote in message news:bns9au$mkm$1_at_mantis.golden.net...
> >
> > "Marshall Spight" <mspight_at_dnai.com> wrote in message
> > news:TTlnb.35277$9E1.135493_at_attbi_s52...
> > > "Tony Gravagno" <g6q3x9lu53001_at_sneakemail.com.invalid> wrote in
message
> > news:m9frpv4cnne4ud0li8f67ll0oveeefif38_at_4ax.com...
> > > > A relational
> > > > DBA can make the same mistake of improper definition as a MV coder
can
> > > > in his app code. In both cases the error would be caught and fixed
> > > > immediately.
> > >
> > > Agreed. (Although perhaps "immediately" is a bit optimistic. :-)
> >
> > I disagree. A DBA's application error has no ability to subvert the
declared
> > integrity constraints.

>
> Hmmm. I was under the impression we were comparing a DBA's constraints
> with a programmer's apps. It is certainly possible for a DBA to make an
> error in writing constraints.

If we are to compare apples to apples, we must compare one system of constraints and applications with another system of constraints and applications. Pick blurs the issue by requiring one to embed constraints in the applications.

As I remarked elsewhere, an erroneous constraint does not corrupt data, but only allows data to become corrupt. One must postulate two errors on the DBA's part: one error in the constraint and one error in some other action that changes the data.

Constraints protect data against DBA error as much as they protect against any other user error. Admittedly, a malicious DBA can easily subvert the protection by first removing the constraint and then sabotaging the data, but that is a different matter altogether. Received on Fri Oct 31 2003 - 15:24:21 CET