SQL Antipatterns |
Author: Bill Karwin Does this book live up to its subtitle, “Avoiding the Pitfalls of Database Programming”? As programmers, we’ve all faced the situation where you’ve a problem to solve and have to work out how to program your way around it. Databases are notorious for giving you ways to solve problems that will make your app run like treacle, or options that look like they’ll be fantastic only to lead to their own set of problems. This book looks at twenty-four such ‘gotchas’ that you’re likely to encounter when writing database apps. In each case Bill Karwin shows how the ‘obvious’ answer has problems, and makes one or more suggestions about what he thinks is a better solution. The obvious answer that has a problem is what Karwin describes as an antipattern.
The book splits the problems into four subsections - logical database design, physical database design, queries, and application development. Karwin is on very firm ground when discussing the theory of databases, and the format works well. Each chapter starts with a short discussion of the problem, usually phrased in terms of ‘I was once working at a company where I was asked to do xxx’. The easy to read description means you get a good feel for the practicalities of what Karwin is discussing. He then goes on to describe the antipattern. For example, in the chapter on restricting valid values in a column, he talks about the obvious answer of storing the valid entries in the column definition using a check constraint or ENUM. He then looks at cases where this would work, before suggesting that a more flexible solution would be to create a lookup table. This chapter gives a good idea of the level of some of the book; using a lookup table is hardly a ground-breaking idea, but beginners will be tempted by storing the values in the original table. Quite often the ideas discussed are valid, but if you’re an experienced programmer you’ll probably have encountered them elsewhere. In the section on logical database design Karwin has chapters on normalization, hierarchical data, primary keys and foreign keys. The section on physical design covers data types and indexes. In the query section Karwin looks at how to write queries to identify Null values, ambiguous groups, full text searches, complex searches and implicit columns. The final part of the book covers passwords, SQL injection, data discrepancies, error handling, documentation and testing. Those topics may sound similar to many other books, but Karwin writes in an engaging way and makes some interesting points. Overall, the book makes the case well for a classic view of database programming and design - normalized forms, good database models. There’s nothing revolutionary, but the way the problems are explained makes clear why the conventional answer has been arrived at. Of course, in most cases there are compromises to be made, so picking solution ‘a’ will work well in some ways, but have drawbacks in others, and Karwin explains what those costs and benefits will be. I enjoyed reading this book; it felt like I was listening to an experienced database programmer talking about life at the coal face. However, I have to be upfront and say that if you’re an experienced database programmer, you’ll probably have learned the hard way about many of the problems discussed in the book. I’d certainly recommend reading the book to anyone who’s just starting to work with databases, the descriptions here could save you weeks, or months, of grief.
|