Re: Multiple specification of constraints

"Jerome H. Gitomer" <jgitomer_at_erols.com> wrote in message news:404a22a3$0$3084$61fed72c_at_news.rcn.com...
> Dawn M. Wolthuis wrote:
>
> [Big Snip]

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

I think this is the best reason I can see for separating these roles. I don't think it is good enough in most cases, however, to put up with the side-effects such as:

1. code that has duplication of constraints (as is the topic here)
2. meetings and more meetings to have people attempt to agree when they have such different goals which is often the case when putting a dba and a programmer in the same room
3. high cost of ownership of software due to cost of maintenance including changes to "constraints" in multiple locations, multiple people & skillsets required to make changes, etc.
4. and a few others, but I'm boring myself (sorry, I'm guessing you're bored then too).

When the issue is whether to drop a bomb somewhere, then I want checks and balances. When it has to do with painting a wall in my house, I really don't want the speed & quality of committee work on that effort. I guess I'm saying that the risks that the average company with the average information system has to accept in not separating these two roles is worth it in most cases. --dawn Received on Sun Mar 07 2004 - 19:01:21 CST