Ed Elliott argues that automation and testing can make code reviews easier:
OK so if we break this down into what a DBA should be doing as part of a code review:
– Ensure formatting is correct and any standards followed
– Have they introduces a SQL injection vulnerability?
– Consider any side effects of the actual change, for instance altering a clustered key on a 1 billion row table will take time – is this possible on a live system?
– Consider any performance effects – is this more prone to tempdb spills? How about deadlocks? Is the plan going to be terrible?
– Is the code going to do what the developer wants? Do they have the update statement correct in the merge statement?That’s a lot, how can we help developers understand enough so that they can review their own code and cause fewer issues in production?
I believe this is a bit aspirational. Nevertheless, if you do get there, life gets easier.