Refactoring Databases
In my consulting, I often run across clients who are getting pretty good at code refactoring, but who are hampered by the need to live with a database structure that is getting old and crufty. Sometimes I can give them some useful advice, since I have a lot of database work in my background, but I’ve never worked in a situation where a database needed refactoring, so mostly what I have been able to do is to cajole them and encourage them to figure it out.
Scott and Pramod have done a lot of the figuring out for us. They provide about 70 named refactorings, like Drop Column, Introduce Soft Delete, or Replace View with Method(s). Each refactoring includes a section on Motivation (why we might want to do this), Potential Tradeoffs, Update Mechanics, Data-Migration Mechanics, and Access Program Mechanics.
The latter two are particularly helpful, in my opinion. I’ve noticed that many database refactorings are deferred indefinitely because folks can’t figure out how to do them without breaking existing programs. Data Migration Mechanics addresses how to make the change in two steps, first putting in the new feature and making it available, while leaving legacy code running, and then later removing the legacy support after all programs have been updated. Some of the migration examples are quite elegant, and will help get you in the right frame of mind.
Access Program Mechanics sections address the changes you’ll need to make to the programs that access the data, pointing out various aspects that you’ll need to be concerned about.
If your project uses database technology, whether it’s a new project or an existing one, this book can help you become much more Agile with respect to database changes. I like the book, and I think you will also.