Refactoring SQL Applications

Chapter 8. How It Works: Refactoring in Practice

Riguarda bene omai s ì com’io vado Per questo loco al vero che disiri, Sì che poi sappi sol tener o guado.

Observe me well, how through this place I come Unto the truth thou wishest, that hereafter Thou mayst alone know how to keep the ford.

—Dante Alighieri (1265-1321)

Paradiso, II, 124-126

(trans. Henry W. Longfellow)

IN THIS BOOK, I’VE TRIED TO EXPLAIN THE VARIOUS PATHS YOU CAN EXPLORE TO REFACTOR UNDERPERFORMING SQL applications. In this short chapter, I will briefly describe how I usually proceed when I am asked to look at a database application that doesn’t live up to expectations. I’ll try to be both concrete and abstract: concrete because I want to show refactoring in practice and abstract because I want to describe mental processes, not give a mock demonstration. Needless to say, you will find justifications and detailed explanations in the previous chapters, but not in this one.

Can You Look at the Database?

Very often, there is a vague rumor that something is wrong with an application, but you are asked to fix whatever you can without knowing exactly what the problem is.

• If you are lucky, the most critical performance issues have already been narrowed to one process or task, and the behavior is the same on a test database as on the main production database. If you are very lucky, someone who knows the functional side of the application well has volunteered to help you.

  In such a case, the best course to take is probably ...