Norman Richards

Despite the fact that I've actually increased the number of technical books I've been reading, I've gotten out of the habit of reviewing them.  I thought I should try and reverse that trend, starting with one of the most helpful books I've read this year, SQL Antipatterns.

I've never been a fan of relational databases.  I started my career working with LDAP, and acceptance of the rigidness relational model didn't come easily.  Over time, I learned to respect relational databases more and become moderately proficient with them.  However, my policy was always that the database is nothing more than an implementation detail.  If I ever actually noticed the database when you were writing code, something was seriously wrong with my dev model.

I won't debate the merits of that attitude, but it led me down a path of accepting many half-baked solutions that ended up causing my nothing but pain, but fortunately I was able to sweep those under the rug of my db abstractions and ORM mapping tools, directing the curses under my breath at that evil SQL database that I had to constantly interrupt my "real" dev work to deal with.

I saw many of those "solutions" in the SQL Antipatterns book, along with a discussion of the problems with each pattern and a pragmatic discussion of the alternatives.  (sometimes the antipattern might actually be better than the alternatives)  I won't discuss the specific antipatterns here.  I'll just repeat that I saw many of my previous design decisions in here along with alternatives I wish I had considered.   If you find relational databases a pain, some of that pain might be caused by the way you are doing things.  SQL Antipatterns may just set you right.   Remember, hating relational databases is not an excuse for mis-using them.   And who knows, when you start using them better you might even find they aren't nearly as ugly as you thought.