The latest science news and current events.
The top science news articles and current events news this week.
Science Resources
Science RSS News Feeds
Earth, Life and Space Science RSS News Feeds.
|
 |
 |
 |
Buy Refactoring Databases: Evolutionary Database Design (The Addison-Wesley Signature Series) by Scott W. Ambler, Pramodkumar J. Sadalage available and for sale on Brightsurf
| View Larger Image | Refactoring Databases: Evolutionary Database Design (The Addison-Wesley Signature Series)
by Scott W. Ambler, Pramodkumar J. Sadalage
| | List Price: | $54.99 | | Price: | $43.99 | | You Save: | $11.00 (20%) |  | | Available: | Usually ships in 24 hours | | | | | Sales Rank: | 40033 | | Studio: | Addison-Wesley Professional | | | Binding: | Hardcover | | Number Of Pages: | 384 | | Publication Date: | March 13, 2006 | | Publisher: | Addison-Wesley Professional |
| |
CUSTOMER REVIEWS (Average Customer Rating: 4.5 based on 20 reviews)
|
Refactoring (Relational) Databases 
The bulk of this book is a catalog of database "refactorings" such as "rename table" or "add column constraint". Each refactoring includes a brief description and the steps you'd go through. There is often also some stored procedure code, with the odd JDBC code or Hibernate configuration fragment. This is all interesting, but a bit tedious to read through from A to Z, so it's best used as a checklist when doing a change (though it's usually nothing surprising).
The more interesting part of the book talks about how to manage and evolve a database in general (e.g. keep a table that tracks all changes that have been applied). But this part doesn't go quite as far as I'd hoped it would, e.g. there is no discussion of how to track down who is using what parts of the database prior to refactoring (proxy driver? access stats?), and the discussion is limited to relational databases (which may not even be the best choice for rapidly evolving data models).
btw there is an interesting open source tool called LiquiBase (apparently inspired by this book) that attempts to help manage (and deploy) database "refactorings" as described in this book.
June 12, 2008 | |
Probably great for DBA 
Probably great for a DBA or if you are executing SQL scripts for everything. I wish there was more on using ORM technologies such as Hibernate.
March 01, 2008 | |
Good for developers 
On smaller projects where you can't have a dedicated DBA this book offers just the kind of expert advice for dealing with existing DBs that you need. Highly recommended for such teams.
June 19, 2007 | |
Excellent overview of a needed approach
Scott Ambler and Pramod Sadalage wrote Refactoring Databases, they say, "to share their experiences and techniques at evolving database schemas via refactoring". The book, particularly in the thorough list of refactorings detailed in later chapters, reveals them to be experienced users of, and writers about, agile development approaches. Their core premise is that data and databases must evolve in the same way as code does - that is incrementally.
They argue persuasively that a big-bang, up-front approach to database design is unacceptable in a modern environment. There is simply too much change and too much uncertainty in the business world for this to be realistic. The basic techniques for evolutionary database design include refactoring (the topic of the book), evolving the data model, database regression testing and configuration management and developer sandboxes. This more evolutionary approach is going to be a big shock for many data professionals, something the authors note, but I think the need for effective evolution and ongoing development of applications and thus their databases is compelling. "Change time", the period after an application (or database) is first deployed is bar far the majority of the life of an application. Techniques that help you cope with this, like database refactoring, are a good thing. Database refactoring as described in the book, is part of an evolutionary approach and with development teams taking on SCRUM, XP and other agile methods it is more important than ever for database teams to do likewise. Many data professionals will likely have the same knee-jerk reaction I did when first approaching this - Why not just get it right up front? But if you believe that agile model-driven development is here to stay for code then you have to accept the need for the same approach to database design.
Martin Fowler's original book Refactoring: Improving the Design of Existing Code made the point that a refactoring must retain the behavioral semantics of the code and this is just as true in databases. The authors take great pains to explain refactoring in enough detail that it you can apply it constantly to keep the database as clean and easy to modify as possible. They emphasize repeatedly the value of test-driven or test first development - even in database design and deployment. The authors stress the importance of testing, especially regression testing, of all the components that access a database when refactoring it. They advise making refactoring efforts small as well as test-driven. They point out that refactoring should be done as a series of small steps and that database develops must not succumb to the temptation to combine refactorings into larger, more complex efforts. The need to treat database designs, and even data, as artifacts subject to change control comes through loud and clear.
The concept of a potentially very long transition period in which both the old and new schemas are supported is a particularly good one. I worry about the organizational dynamics of having the old schema removed by a new team that does not remember the original refactoring but nothing else seems rational in a typical environment where many applications run against the same database. I also liked the paranoia of the authors, for instance in their suggestion to always run regression tests BEFORE refactoring to make sure the database is actually as you think it is! While the book focused on refactoring, many of the hints and suggestions would be good for implementing real changes in business policy.
The book is a surprisingly easy read for such a potentially dense subject. The book starts by describing the fundamentals of evolutionary database development and the basics of refactoring. A process overview, deployment notes and some best practices follow. These initial chapters, designed to be read in sequence, introduce and explain the topic well and have a nice little "What you have learned section" at the end. There were many worthwhile asides in the book as it covers these topics and after these introductory chapters, the book then goes (somewhat abruptly) into a series of chapters on various kinds of refactoring - structural, data quality, referential integrity, architectural, method and transformations. These chapters take a series of very specific refactorings. The potential motivation, tradeoffs and implementation mechanics are defined for each. The refactorings are self-contained and, while this makes reading them as a set somewhat repetitive, it should make the book a much better reference guide for actual users.
The book did not really touch on how you should consider data and database designs used in analytic models or the potential value of using business rules, but these are minor quibbles. The book is well written, full of great examples and gives lots of good advice.
May 25, 2007 | |
Database maturity
This book is helpful for applying the basic coding practices that have been so useful in keeping code in good shape to the messy world of the DBA. It was always shocking to me how poor most DBAs were at making changes to their schema and the data. The great ones I have worked with already did a lot of stuff in this book- use scripts, etc. The other ones need to learn- and developers need to learn to if they are working sans DBA.
January 03, 2007 | |
SIMILAR PRODUCTS |
| |
|
|
|
|
