SQL Server Team-based Development - Red Gate Software

Chapter 11: SQL Refactoring
Code refactoring is the process of improving existing code in some way, while leaving its
input/output behavior unaltered. The most common reason to undertake a refactoring
effort is in response to performance issues, but refactoring could also be used to improve
code security, error handling, maintainability (e.g. decrease coupling), and so on.
The emphasis on leaving the program behavior unchanged is crucial; our refactoring
must not add or remove functionality. Code refactoring may drastically alter the internal
logic of a database object, and we may add new objects (columns, tables, views, indexes,
and so on) to support our refactoring efforts, but the black-box behavior of the code, as
a whole, must remain the same, and we must verify that this is the case through careful
black-box testing.
This chapter will focus on refactoring SQL code in standard SQL objects such as stored
procedures and functions, rather than on full-scale schema refactoring (splitting tables,
and so on). The reason for this is simply that, in my experience, most opportunities in the
real world for database refactoring take this form. Opportunities for full-scale refactoring
of the base tables are rarer; too many dependencies. However, it's worth bearing in mind
before we start that, if the database design is fundamentally flawed, there may only be so
much you can achieve by refactoring the SQL application code.
Why Refactor SQL?
As noted in the introduction, probably the most common reason to refactor code is to
improve poor performance. Sometimes, an application is inadequately tested during
development and then simply fails to meet performance requirements when deployed to
production. At other times, a successful legacy application is now handling data volumes
and user numbers that were never envisaged when it was designed, so it has begun to
310