 |
If you ever read Martin Fowler's original Refactoring For each refactoring, the authors take a structured approach that crosses the DBA and development domains. They lay out the motivation for the refactoring, the potential tradeoffs, the actual mechanics of changing the schema, the mechanics of migrating data, and the necessary updates to any access programs. The three "mechanics" sections are likely to be the most valuable to experienced professionals. You may, for example, have a good handle on the fact that you'd like to change a column to use a standard data type to conform to a corporate standard, but have you really thought through all the implications of this move? Ambler and Sadalage give you a good solid checklist of things to consider, from identifying the impacts to rewriting the application code. The book contains several dozen refactorings, grouped into five chapters: structural refactorings (adding, dropping, and renaming database entities), data quality refactorings (mostly classic normalization moves), referential integrity refactorings, architectural refactorings (such as adding CRUD methods or migrating methods to or from application code), method refactorings (changing interfaces or changing the logic in database code), and transformations (adding new features to the schema). Others will no doubt invent other database refactorings, but it's a good starting catalog. Beginners will do well to read through the entire list, noting patterns for future use; more experienced practitioners will be able to skim the list and find things that apply to their current problems. Some of the ideas here will be nothing new to experienced DBAs, of course, who will see them as nothing more than standard normalization. And viewed on a micro level, no single piece of advice here is likely to strike you as revolutionary. The importance of the book comes, I think, in its attempt to put some structure around the process of evolving and refining a database design as part of a suite of applications. The authors discuss issues like regression testing and test-first development and deploying into production in the context of databases. While it can be difficult to find tool support for these ideas, depending on your software environment, they're an important part of moving your application development away from chaos and into a more controlled regime. So even if you don't end up taking a refactoring approach to database work, you may still find this an inspirational and useful book.
Mike Gunderloy is the lead developer for Larkware and author of numerous books and articles on programming topics. Published April 10, 2006 |
Refactoring Databases, $49.99