Re: Multiple specification of constraints

From: Dawn M. Wolthuis <dwolt_at_tincat-group.com>
Date: Wed, 25 Feb 2004 19:27:29 -0600
Message-ID: <c1ji26$mqj$1_at_news.netins.net>


"mountain man" <hobbit_at_southern_seaweed.com.op> wrote in message news:56b%b.76496$Wa.14645_at_news-server.bigpond.net.au...
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> news:c1iq4p$6dp$1_at_news.netins.net...
> > This is a partial response to Eric's previous e-mail.
> >
> > Where should constraints be specified?
>
> ...[trim]...
<snip>
>
> What happens when you have two sources for
controls/constraints/validations?
> The answer is that there must exist and be maintained coordination tasks
> which
> ensure that the two sources are consistent. This is from a 'flat
> operational view'
> that looks at the total system of a day-to-day basis.
>
> The other type of view is dynamic, incorporates far longer time scales and
> must
> face the problems associated with change management and evolution of an
> entire
> system. It is from this perspective (change management) that the
> coordination
> tasks that are described above become extremely complex in themselves, and
> often require serious resources (or additional costs).
>
> For example, assume you implement such a non-db centric "minder of
controls,
> constraints, validations, etc". After a while, the organisation somehow
> expands
> its operations into another business area, and you acquire another one, or
a
> set
> of new databases and applications to maintain. The organisation now wants
> to
> integrate the lot, and have it operational before it announces its next
> acquisition.
>
> Change management is the final testing ground of good ideas, so do your
> ideas
> still appear sound if the environment is undergoing critical change? How
big
> do
> the coordination tasks become before you hire another person, or buy some
> more software?
>
Good point.

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. 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.

--dawn Received on Thu Feb 26 2004 - 02:27:29 CET

Original text of this message