The first thing that intrigued me about Prentice Hall's The Data Access Handbook: Achieving Optimal Database Application Performance and Scalability by John Goodson and Robert A. Steward is that the book blurb is aimed solely at application developers. It's the only time I've seen a database/data theory book description written specifically for this audience.
In the last 10 years or so, the vast majority of slowdown in applications that use databases has shifted from slowdown on the database server itself to slowdown on (or caused by) the application server. The problems at the application level include database driver issues, connection pooling misconfigurations, being too "chatty," and so on.
While many organizations have a database expert take a look at the SQL code or the database itself, many applications have all sorts of inefficiencies that cannot be addressed at the database level. The Data Access Handbook addresses these exact kinds of issues, so that your application can perform its best. (Download a sample book chapter, which details how to design your application database for performance.)
The book is filled with a lot of great information. I learned more about the "under the hood" end of database connectivity in the second chapter than I have in the last few years working in the field. It went in-depth into topics that documentation I've been exposed to did a poor job of explaining. For example, when I was working with Java, my coworkers told me, "use connection pooling — that will make things go faster," but no one quite knew why, and no one mentioned the dangers of having too many connections in the pool. And you could forget about getting anyone on the team (including me) to know how to configure that connection pool for optimum performance; without understanding the principles and theory behind it, how could we? By reading this book, you can close this kind of knowledge gap.
The authors spend a lot of time talking about database driver details. I honestly never knew there were options; I thought you used whatever the DB maker gave you for your platform and language, plugged in a server name, username, and password, and it "just worked." After reading this book, I'll never look at a database driver the same way again. I'll also never look at hooking an application to a database the same way.
One thing that stuck out is that there are separate chapters addressing the concerns of developers using ODBC, JDBC, and ADO.NET to access the database. All three chapters are substantially similar, even sharing identical paragraphs; this isn't a problem, since the shared information isn't technology specific. Although it does feel like the ADO.NET chapter has a bit more information in it than the other two chapters.
There are two really good chapters near the end of the book: One is on how to benchmark your application, and the other is on how to determine where the performance bottlenecks are. Both chapters focus on information that, while intuitive to some developers, is good to spell out. For example, the benchmarking chapter contains the "obvious" suggestion that a test run longer than a few seconds, since the application's initial startup, assembly loading, etc. will affect the test numbers. I know developers who don't take that sort of thing into consideration when testing applications, so I know this is the exact kind of information that a lot of people need.
There are only a couple of things I didn't like about the book. The main issue is repetition of many of the same points; granted, the points are important, and maybe some developers really need things to be driven home hard. After a certain point though, I felt that some things had been repeated past "making sure you remember" and into "I'm getting numb."
The other minor issue is there's a discussion on SOA at the end of the book that I think is unnecessary.
It's a winner
The Data Access Handbook is a must-read if you're accessing a database in your application. At just over 300 well-written pages (that are not drowning in dense technical terms), it's a fairly quick read. If anything, I wish it was longer, although I think the authors would have needed to exceed their stated scope to add more to it. Overall, it would make an outstanding addition to your tech library.
J.JaDisclosure of Justin's industry affiliations: Justin James has a working arrangement with Microsoft to write an article for MSDN Magazine. He also has a contract with Spiceworks to write product buying guides.
———————————————————————————————————————————-Get weekly development tips in your inbox Keep your developer skills sharp by signing up for TechRepublic's free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!
Justin James is the Lead Architect for Conigent.