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.