Re: Data Constraints Vs Application Constraints

From: David Cressey <david.cressey_at_earthlink.net>
Date: Fri, 11 Mar 2005 18:47:17 GMT
Message-ID: <VIlYd.1265$qf2.401_at_newsread2.news.atl.earthlink.net>


"FrankHamersley" <FrankHamersleyZat_at_hotmail.com> wrote in message news:enfYd.193299$K7.142983_at_news-server.bigpond.net.au...

> Personally, as a bit of a cynic, I am yet to be convinced (but remain
> open to suggestion) about the benefits of an all encompassing
> referential and cascading schema etc. I can recognise the apparent
> desirability of these aims but remain suspicious of the marketing types
> who glow about this feature or that.

Frank,

My attitude is somewhere between yours and Alfredo's. I have seen the benefits of a well built schema with a good scale and a good scope. And I've seen the before and after difference between businesses before I modeled their data and after.

The benefits are real, provided you don't bite off more than you can chew. And there's the rub. Most of the "all encompassing" schemas that failed bit off too much, and weren't able to chew it into something the enterprise could digest and assimilate before the money and the credibility ran out.

At the same time, I would hesitate at labelling everyone whose work is not as good as mine as "incompetent". And yet another reason to be cautious is that "goodness" is multidimensional.

>
> What I have observed in a few cases that very tightly meshed systems
> become majorly stuffed when the physical side breaks down as computers
> are want to do. The main issue arises when data fixing is prevented by
> the rules...of course the more modern DBMS provide improved methods to
> conduct these out of band activities but for me it's still a hung jury.
>

This is what DBAs are for. Preventing physical breakdowns from resulting in loss of data or denial of service.
Also, DBAs are for fixing the data when the rules say you can't.

But, in the normal course of events, the usual things happen.

> Fools rush in and I don't intend to. I note that for all these
> "advances" there is still not an apparent change in the % of failed IT
> projects...unless someone can refer me to a well prepared and contrary
> article on that subject.
>

I think the industry average is a poor measure of the value of the right approach. A large number of failed IT projects had no one on board with the skills of either Jan Hidders, or Alfredo, or Joe Celko, or Dan Morgan, or myself. Or, if they did have such a person on board, they didn't listen.

Unfortunately, the programming community still thinks that file cabinet design is about as profound as database design. It's not. And by the time most people figure that out, they are trapped by their own history. Received on Fri Mar 11 2005 - 19:47:17 CET

Original text of this message