Over the past year, my main job focus has been to improve my employer’s SQL code base. This particular code base was acquired approximately one decade ago and extended significantly since, but those extensions left behind a significant amount of technical debt.
There are a number of books, videos, and blog posts dedicated to handling legacy code—in fact, I’ve adapted the title of one of the most famous books in this genre for my series—but these books tend to be focused on procedural or object-oriented languages and many of these recommendations actually end up being T-SQL anti-patterns (especially using nested views and user-defined functions).
My goal in this series is to come up with a guide for how to refactor SQL code in a way that makes your life—as well as that of your successors—much easier. Some of this will look familiar to people well-versed in refactoring, but there isn’t a perfect overlap in methods, so hopefully this will be interesting even to people with a great deal of experience refactoring object-oriented systems.
Throughout this series, I’m going to include a lot of examples and details. These will be anonymized enough to protect the innocent, and they will include work from a number of previous employers. The stories are intended to illuminate the problem and solution rather than act as a series of rants tied together with advice…yeah, that’s the ticket…
36 Chambers - The Legendary Journeys: Execution to the max! 
5 thoughts on “New Series: Working Effectively With Legacy SQL”