Re: Data Constraints AND Application Constraints

"Paul" <paulsnewsgroups_at_hotmail.com> wrote in message news:9mtj31h1qs195jimmle1rg6sa1r6mpbfpk_at_4ax.com...
>
>
> "David Cressey" <david.cressey_at_earthlink.net> wrote:
>
>
> >> But surely for a rule like the one above, you would also implement a
> >> constraint in the db?
>
> >Well... yes I would. But my argument about the DBMS better using it's
> >resources stands.
> >If it's implemented in both places, the DBMS will still experience less
> >traffic, because it won't
> >see the bad transactions that get snagged by the application.
>
>
> But the whole point about this is that that's probably fine if you are
> a single developer who is writing one app against the db - your baby!
>
> Then company gets taken over and 5 new apps are being written against
> the db. You've retired to the Caribbean and the new programmers don't
> have a clue. What happens then?
>
>
Paul,

I think you missed the entire point of my last post. Please reread it. I was talking about the nbenefits of imlpementing the constraint in BOTH places. One benefit is less traffic for the DBMS. And, as I said a few posts ago, the exception is referential integrity. Well, reconsidering, I'd also make an exception for entity integrity (the no duplicates rule).

Both entity integrity and referential integrity should be implement in the db and not in the app. Value datatypes, ranges, and omission of manadatory values should be checked in both places for values that are not hidden inside the app. This is what I've been saying. I think you agree with this, and misconstrued my remarks. Received on Thu Mar 17 2005 - 22:44:54 CET