Re: Multiple specification of constraints

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

> I'm just thinking out loud and I'm sure something I wrote was not
brilliant,
> but help me out here -- isn't this a real issue in application software
> development written today? I'm suggesting something rather radical --
> decouple the constraint specification and validation logic from the
> database. Does anyone agree?

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?

Pete Brown
Falls Creek
Oz Received on Thu Feb 26 2004 - 01:29:53 CET