Re: Multiple specification of constraints

From: mountain man <hobbit_at_southern_seaweed.com.op>
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.

Programmers and DBA's usually are guided by what the IT manager may decide. In Australia, the usual practice is that there is one single person responsible - in the end - for decisions. I dont know how you run things in the north of the planet, but there are times for meetings and there are times for decisions.

Your points 1 - 3 above would normally be resolved at the IT management level, and dependent upon the "technical philosophy" of that person, so the decisions and policies get made, etc.

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

Original text of this message