Refactoring Databases - Short Review

Considering the deadlines most of us have to work to it’s not surprising how much the idea of refactoring, which by continuously improving the design of code, we make it easier and easier to work with. appeals to us. But why should developers have all the ‘fun’? Databases need some love and care too!

It’s easier to review this book if we look at it as two smaller books. In the first book, chapters 1 to 5, the authors take you through the details of Refactoring Databases.

I think this is the most useful section of the book for most people, and the only part they’ll read start to finish. It covers how the agile development and defensive data worlds can be combined (and has some slightly harsh DBA stereotypes), possible processes to follow and miscellaneous details such as transition periods, how to have two versions of a schema in production (triggers, lots of triggers!) and covers all the basics you’ll need to be able to make informed decisions about how refactoring databases can fit in to your work flow.

The rest of the book is filled with the explicit, and quite dry refactorings (and a chapter of transformations). They go in to a surprising level of depth but are mostly common sense and easily understandable from the refactorings name.

The best advice I can give it to have a look at the inside front and back covers. If the refactoring names look interesting but you have no idea how they’d work then the books a good read and you’ll come away with some insights in to hands on database refactoring. If you can think of two situations when to use, and just as importantly, not use, each refactoring then the book’s too basic for you.