Re: Multiple specification of constraints
Date: Sun, 7 Mar 2004 19:01:21 -0600
Message-ID: <c2ggl5$crt$1_at_news.netins.net>
"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.
- code that has duplication of constraints (as is the topic here)
- 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
- 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.
- 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 Mon Mar 08 2004 - 02:01:21 CET