Re: Data Constraints Vs Application Constraints

David Cressey wrote:
> "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.
>
Spot on - this often happens when the marketing types "hypnotise some chooks" or when excitable types imagine all the problems they can solve with a swift stroke using the latest and greatest (even if unproven) gear.

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

Exactly - one persons (sic) meat is ...

>
>>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.
>
True - I'm not convinced the tools and techniques have advanced as far as the demands. My recent experience has been on systems that don't have fat windows of free time to put the system into single user mode whilst the schema is broken for a data fix so I like to avoid intractable problems. As you know Murphy's Law applies to these situations.

>
>>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.
>
Managing this interaction is as much a responsibility of the informed ppl. It's no defense IMO to know the good oil, but because of a poor approach to conveying the implications to the unwashed, to see the wrong decisions taken.

> 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.
>
Sad but true!

Cheers, Frank. Received on Sat Mar 12 2005 - 14:03:26 CET