T. Burket said
Even though the book is over five years old, its principles still apply today. Time has been good to the maturation and deployment of agile practices, as what Mr. Ambler said in 2003 has become more conventional thinking. His advice and best practices make for excellent reading.
Agile development is really only a subset of the book, with an introduction on agile development and a sales pitch for its adoption. In some sections, agile is woven into a topic, such as refactoring, that stands on its own with or without agile methodology. I can easily imagine material that started as essays on solid best practices being updated with the latest thinking, including agile.
Our organization does not use UML and has no intention to do the detailed modeling that Mr. Ambler suggests. Readers in similar situations may consider those parts looking for ideas or quickly skim them without disruption to the rest of the arguments.
I have read Scott Ambler in various contexts and his insights are always welcome. He knows the issues involved in development, including database-oriented projects, as demonstrated by his ability to touch lightly or go deep. One of the highlights here is that he articulates tradeoffs. Well, you could do this, or you could do that, and here are the issues to consider, wisely deferring the analysis and decisions to actual projects.
D. Long said
If you are an application developer that has ever worked with a system that is difficult and convoluted because of fear of touching the Database then you owe it to yourself to read this book. This book will provide you with the insight and techniques to make changes to your Database with confidence.
I also recommend Refactoring Databases: Evolutionary Database Design (The Addison-Wesley Signature Series) for those who seek details on how to implement the topics discussed in "Agile Database Techniques"
martin dreis said
To be fair, the book title suggests that it is for the software developer, and not a database administrator. I thought that it had a good overview of agile related items. Although it was probably not as useful for software developers who might have more exposure to the agile methods. From a DBA point of view, I thought it was a nice overview because agile is not typically used in DBA teams.
As far as specifics relating to databases, I thought it could have had more real-life scenarios and suggestions on how to deal with them. Some of the ideas presented were just too unrealistic for my liking.
That being said, there are a few good ideas in this book. It was a quick read too. So if you are a DBA who has no idea of agile, it might be something to start with.
Thing with a hook said
This is very well written, enjoyable book, with few (if any) competitors. Given its agile sensitivities, it's perfect for a programmer looking for an overview of the whole data modelling she-bang, from use cases to impedance mismatch. Despite clocking in at 400 pages of fairly dense type, interspersed with various tables and UML diagrams, it's a breeze to read. It assumes a bit of knowledge of database technologies, but you don't need anything more than a nodding familiarity with SQL and basic concepts like normalisation.
This book deals with a lot of issues related to using databases as part of agile modelling. The main message is that agile application developers need to think about persistence issues, and database admins need to understand agile development. The differences between data-driven and object-driven models are clearly laid out, and there's an excellent section on refactoring databases.
The important thing about this book is not so much offering you specific solutions to problems, but alerting you to potential problems you might not even know exist, and explaining that you do have options in solving them. As well as introducing agile methods like TDD and refactoring, it also covers database issues like transactions, security, concurrency and object-relational mapping.
Additionally, there is an emphasis on the organisational and political issues you might face in transitioning to agile methodologies, and it's very pragmatic in pointing out that some things that might be considered the preserve of an application developer, could be done in the database itself. The issues are presented at the same level of detail as those presented in the likes of The Pragmatic Programmer (but a different subject, of course). For more specifics, you will need to turn to the likes of Martin Fowler's Patterns of Enterprise Application Architecture, or to see specific technologies being used, Chris Richardson's POJOs in Action. I would definitely recommend this book before reading those.
As someone with little knowledge of databases, I found this an excellent and unique resource to join up the dots when it comes to persistence and agile.
Randy Lane said
The book was well written and very easy to use. I found many insightfull thoughts as to the purpose of Agile development. If you are looking for a great book to guide you into AGILE development, this will do it.
Drawbacks or missed points, yes this book has two flaws that I have to list. 1. the repeated use of the word Legacy and the very negative congnitation of the word. Older database will have many flaws, and we need to identify them. They will also have many objects and data patterns that are valid and efficient and should not be abandoned because its not todays effort.
2. Agile and refactoring of tables does not address, production, zero down time, large volume databases. How do you refactor a table with 2 terabites of data and can not allow downtime. (medical)
Comments