Re: Multiple specification of constraints

Dawn M. Wolthuis wrote:

        [Big Snip]
>
> It is a lousy example, but if you can stick with it this "local constraint"
> (one that applies to this application related to the database, but not to
> other applications on the same data) is one that has me putting a dropdown
> list of values 2, 3, 4, & 5 for the user to choose from. Where did the
> application get those values? From somewhere in the non-database side of
> the application, I'm guessing. Why? Because I, the programmer, can control
> the constraints here so that when 6 becomes a valid value, I can change my
> dropdown list without anyone else involved. This has to do with human
> beings and how they work. Programmers will almost always do what they see
> as having the best quality solution from their perspective and that
> perspective is often at odds with what a dba would see as the best quality
> solution. If both could manage validation/constraint specification/logic
> within the same environment ...
>
> Anyway, it relates to the same point I started with -- that the way we have
> our system development partitioned today and where we have our constraint
> processing handled, we end up with multiple specifications of
> validation/constraint handling. I don't think our systems should be
> partitioned the way they are, nor do I think the roles on the project team
> should be partitioned into dba's and programmers.
>
> --dawn
>
>

You might partition your system development that way, but some of us use a different model. For example, I use a model based on the concept of noun and verb. Verbs (procedures) operate on Nouns (Data). Data is further divided into two categories: Control Data and Application Data.

Using my model your dropdown list would be Control Data stored in a table and could only be changed when the installations change and validation criteria were satisfied.

My model perpetuates the dba and developer project team for good reason -- Separation of Authority. It reflects the need for commercial enterprises to protect their data from change except through authorized, controlled and monitored processes. Those who control the data should not develop the procedures that operate on the data and those that develop the procedures should not be responsible for the integrity of the data. Experience has proven that it is too risky to do otherwise -- not from a systems point of view, but from the point of view of the enterprise that owns and uses the data.

Jerry Received on Sat Mar 06 2004 - 20:12:43 CET