Re: Multiple specification of constraints

"mountain man" <hobbit_at_southern_seaweed.com.op> wrote in message news: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]

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

>

Yes, one thing IT management does is resolve issues when two or more people on a project team are not in agreement. That's how I know that DBAs and programmers often have very different goals. I'd prefer that everyone building my house have the same goal in actually building a quality house into which I can move.

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

ugh! That's what gets us to the topic at hand as it is -- the way that constraints are handled in today's DBMS's, from what I can see, is to employ constraint logic when CRUD services are requested, rather than having the necessary constraints available to the GUI developer, for example (I'm being a broken record, but ...)

> Most things are better change-managed centrally than distributed.

Maybe in 1988 the database was a central repository for all data a company cared about, but that isn't the way it is today. The DATA ARE DISTRIBUTED -- so then you get to that "federated" term and all, but what you can do to centralize the constraint logic is create services for use by any and all that need it. How do you ENFORCE the use of these services? You can require the CRUD services for any databases you do "own" to employ these services, for one thing. And then there is the carrot rather than the stick for your GUI and other components -- if it is easier to use the data constraint services than not to and to change them when needed, then we can guess what will happen.

--dawn Received on Mon Mar 08 2004 - 21:26:46 CST