It doesn't work that way in my shop and shouldn't work that way in any shop. Just because a DBA is directly related to the "all powerful OZ", doesn't mean they have the right to change any code without it going through testing and redeployment.

In our shop, all T-SQL goes through a DBA peer review. I use these peer reviews as time for 1-on-1 mentoring which has really improved the quality of the original work and has greatly reduced rework and performance problems especially as a database scales up. The code then goes through QA and any changes to the code must be re-reviewed by the DBA (me, if you haven't guess that already) no matter how trivial the change may be.

Once code has successfully QA'd, even I can't change it without it going through a peer review with the Developer and retest by QA. Once it's in production, NO ONE can change it without it starting the process all over again.

While that may seem slow and arduous to many, rework is 8 times more expensive and I don't need to tell you how costly a "mistake in production" can be. Because of the peer reviews, we've cut QA and rework time down substantially. The little bit of extra work up front has saved us shedloads of time lost on even trivial problems.

And, yes. If you've properly written your DB code, you can, in fact, just replace one section of code with another and Bob's your Uncle. Good database code is not abstraction resistant.

For shops that have made the mistake of allowing Developers and DBDs to promote code directly to production themselves, thank goodness a DBA can intervene. I do blame some of that mistake on the DBAs themselves because they've not made the need for Peer Reviews and QA understood beyond any reasonable doubt.