Re: Multiple specification of constraints
Date: Mon, 08 Mar 2004 20:35:41 GMT
Message-ID: <xO43c.93799$Wa.34313_at_news-server.bigpond.net.au>
"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
news: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.
>
> 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
The roles might simply be two hats that one person wears. The principle in question here is the multiple specification of constraints.
When systems get large, or when there is much change happening then these constraints need to be centralised in the DB.
After all, the whole point of a DBMS is to have I/O. Those who dont want to "waste valuable i/o" on performing database constraint or validation checking might consider allocating funds to a get better CPU if the validation i/o is not quick enough for the users.
Some solutions obviously seek middle ground, such as caching the data control-data locally.
That person should also be able to implement short-term workarounds of changing application code to present a new set of contraints, if the RDBMS cannot be prepared "overnight", and to oversight the changemanagement of this, and its coordination with the existing operations.
But in the end, change management (of the RDBMS and the applications) is the most expensive item in IT today. And it is for this very reason that the tendency to move all constraints to the RDBMS is growing.
Most things are better change-managed centrally than distributed.
Pete Brown
Falls Creek
Oz
www.mountainman.com.au
Received on Mon Mar 08 2004 - 21:35:41 CET