Re: RI - pros and cons

"Ed Stevens" <spamdump_at_nospam.noway.nohow> wrote in message news:3c98f481.201021974_at_ausnews.austin.ibm.com...
> I feel stupid even posting this question but there's trouble brewing in
River
> City. I'm getting caught between my "partner" DBA (with whom I have many
> philosophical differences) and the developers.

Let the company developers fight the battle. If they won't do it, then document your recommendation, make sure management and other witnesses see the docs, and go with the flow. Also, make sure you get them to identify the accountable party and make sure it is not you.

If problems arise later, and you are still around, resist the "I told you so". Fixing a problem in production costs ten times what it would have cost to prevent it in development. Just have a good laugh as you cash the big check you got from fixing the production problem.

>
> New application being developed. Four rather simple tables - header data,
> detail data, and a couple of reference/look-up tables. Developers want RI
and I
> agree. DBA says "RI is more trouble than its' worth. You should take
care of
> it in your application."

What he really is saying is that he doesn't want the responsiblity of maintaining integrity in the database. So, if the application screws up, he is not held accountable.

Regardless of where you implement RI, try to keep the rules in one place. If RI is spread all over the place, it becomes difficult to maintain consistently. This is probably the number one reason to put it in the database. Also, if it is in the database, it can't be easily circumvented.

> I'm caught in the middle, stongly disagreeing (that's
> putting it diplomaticly) with the other DBA but having to maintain a
working
> relationship. He makes the claim "all the other DBA's I read on MetaLink
say RI
> is too much trouble" but won't produce evidence.

Heresay is not admissible evidence. Counter by saying that the DBA's that screw up their data because they don't use RI would not dare to publicly admit it on MetaLink.

> Anyone want to comment on the technical merits of RI vs. not. I've always
felt
> that the benefits of RI (and normalized tables) was so obvious as to not
even
> require any further justification. Do I need to be re-educated, or . . .
.

To RI or not to RI is not a technical issue. It is about cost effectively managing risk. If the application screws up and it doesn't matter, then little effort should be put into RI. If the application screws up and it bankrupts the company, then a reasonable effort should be expended to ensure RI.

--
Later,
BEDick