Re: Multiple specification of constraints

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c1ji26$mqj$1_at_news.netins.net...
> If you do not tightly couple any database storage with database validation
> and integrity constraints processing, then I'm guessing (based on
> experience) that you can much more easily react to changes.

This also introduces more points of failure (not in operations, but in logic). More chances of data corruption. Logic phrased in GUI-like terms. If programmers have the choice of placing logic in the GUI, in a "data validation" component, or in intermediate objects, you'll get 10 different answers from 10 different programmers. While code and design review help somewhat, generating those things from a central point is much clearer and less prone to abuse.

> I definitely
> agree that holding specifications and the processing for such constraint
> specs in multiple places is a setup for complexity, cost, and having your
> constraints out of synch. We cannot remove the constraint processing from
> easy access from the GUI because what shows on the screen is based on
theose
> constraints, so I suggest removing them from being so tightly coupled with
> the database that they are inaccessible to the GUI.

Having the GUI driving things is a bad idea. Which GUI? Do you always have just one?

Having the constraints accessible to the GUI doesn't mean they have to be removed from elsewhere.

• Eric