One of the things I teach in our admin course is that it's not enough to just be the gatekeeper/central point of change when it comes to being a DBA, we should be adding value:
- Look at each change and ask ourselves 'is this obviously stupid?'. For example, we might see a case where a cursor is used when clearly a a set based update would work, or we might notice a cross join
- Verify that it meets our coding standards (this is an easy check if you don't have any!)
- Compare the performance of the change with the previous code, and fixing if needed. This avoids the slow and steady entropy that can otherwise result
You'll notice that I don't put in the list verifying the change is correct - that's a QA task!
One sub bullet point I've added to 'is it stupid' recently is checking queries for unused tables. I ran across a couple instances lately of what was probably copy/paste code reuse and I was tuning the queries, realized that several tables were included that had no effect on the results. Easy to miss something when you see things like this so it definitely needs to go back for testing, but it's worth taking the deeper look right then, before you deploy.
