data storage and management

I fully agree with the other reviewers who have given detailed and glowing descriptions of this book and why it is an important work that addresses the real challenges of developing to a relational model in OO environments. Agile techniques are also interwoven into this book, but it is in overcoming the relational-OO challenges that I found this book to be most valuable.

The first part of the book, "Foundational Skills and Knowledge", covers the challenges and how to meet them with eight excellent chapters that truly give the foundational knowledge. The next part, "Evolutionary Database Development", is comprised of seven chapters that introduce Agile techniques as they relate to DB development. Among the two strongest chapters in this part of the book are the ones covering DB refactoring and mapping objects to relational databases. This material, to me, clarified a lot of issues I had before reading this book. Part 3 is more focused on development techniques, with excellent information about concurrency control, access controls and related topics. The final part of the book is specific to general Agile implementation. You need not embrace Agile methods to learn an enormous amount from this book.

If you want to know more about this book's contents you will find a great deal of information on the author's Agile Data web site (paste the ASIN, B0000A3527, into the search box at the top of this page, select All Products and click GO). I also recommend Clifton Nock's "Data Access Patterns: Database Interactions in Object-Oriented Applications" (ISBN 0131401572), which augments this book in many respects.

"Agile Database Techniques" is aptly subtitled "Effective Strategies for the Agile Software Developer". Take special note of the word "strategies", because what you will not find within is pages of code and implementation details. This is not a bad thing as there is so much ground to cover that getting caught up in the low-level details of how to implement a particular strategy in language (add yours here) would have limited the scope of the book. Instead, what you will find is a detailed set of skills and development methodologies required by the developer who finds him or herself immersed in the details of modeling, implementing, and/or refactoring the database schema for their current application.

Should you buy this book? Well, try answering the following questions:

- Could you easily create a physical data model of your schema?
- Can you explain the difference between first and third normal form?
- What about first and third object normalization forms?
- Can you list the challenges in mapping an object model to a data model?

Did you answer honestly? Because these are just some of the items covered in Part One of the book and unless you said yes to all of the above, you will walk away with plenty of ideas for improving your development after a single reading. This is the core reason I would recommend this book. It is full of ideas that you might never have thought to include in your development practices, and probably some that you had thought about but were not sure what the best approach might be.

My complaint with "Agile Database Techniques" is that it could use another iteration. In the introduction, the author states "When I first started writing this book, I intended its focus to be on the agile data method... Because I was taking an iterative and incremental approach to the development of the book, I quickly realized that the real value lay in detailed development techniques instead of yet another methodology." While I can agree with and embrace the merits of applying agility to my development practices, I think there is an overabundance of methodology content in the book that only clouds its real value.

In summary, I think this is one of those books that will sit on my shelf for some time to come as a great reference for how to approach any number of application and database development related items.

Agile Database Techniques is a brilliant book. Already after reading the first chapter I felt like I had been run over by a truck, wondering why I haven't paid more attention to these issues before. Yet, it also has its flaws which I will go into further down.

Ambler starts laying out the groundwork for the second part of the book by introducing his Agile Data method, UML and data modeling. He also gives a very useful jump-start tutorial on data and class normalization and discusses the infamous object-relational impedance mismatch. Worth noting is that in each chapter (throughout the book) Ambler makes sure that the reader understands how the subjects relate to the role of an agile DBA and what should he be looking out for. The subjects in part one were introduced so well that I more than once thought, "I've never seen such a well-balanced and informative tutorial."

The second part of the book focuses a bit on how evolutionary software development is the reality and how techniques such as Agile Model-Driven Development and TDD can assist in surviving in this climate. The chapter on database refactoring is intriguing and the more comprehensive list of database refactorings, found in the appendices, is something I'll definitely Xerox and keep with me in my traveling tool bag. The second part also covers database encapsulation strategies and approaches to mapping objects to relational databases which, again, is a delightfully comprehensive tutorial, as well as touching on the topic of performance tuning.

The third part is a seemingly random collection of subjects such as finding objects in a relational database, referential integrity, concurrency, security, reports and XML with databases. The text is again of high quality and provides an entertaining walk through the woods, but I feel that these chapters had very little to contribute to the subject of the book. This disconnect is made even more clear when Ambler finishes with a 10-page guide on how to become agile and to introduce agility into the organization.

After reading the book, I feel confused. On the other hand, this book is full of little islands of useful insights that I wouldn't think twice recommending for others to read. On the other, the book as a whole is very fragmented and pretty far from what the book's title might suggest. If you pick up the book with an open mind like I did, you'll gain plenty. Otherwise, you'll probably be disappointed to find out that one half of the book probably talks about something you weren't expecting based on the title. After a long struggle, I'm giving this book "only" fours stars despite that it contains some very, very high quality material.