SQL Antipatterns, by Bill Karwin
I remember that when I finished reading The Lord Of The Rings, I felt a pang of disappointment. "What? Already finished? What am I going to read now? What can give me the same pleasure and sense of accomplishment that these wonderful pages have given me?"
That's how I felt when I came to the last page of SQL Antipatterns. And, no, Bill Karwin doesn't tell imaginary tales from a fictitious world. This book is full of very real and very practical advice, but all the material is presented with such grace and verve that I could not put it down until the very end. I read it cover to cover in just a few hours, and I savored every page.
What is this Antipatterns, anyway? The title may deceive a casual bookshop browser into believing that it's about some philosophical database theory. Digging further, you realize that it's a collection of best practice in database handling, but told from the side of the bad practice. Every chapter starts with the story of a disaster, followed by an explanation of why it happened, and how to recognize the symptoms. Along the way, you learn what people do to fix the problem when they don't understand where exactly the trouble comes from. And then comes the best practice section, where you are told of several ways of fixing the problem for good.
It's a pleasure from the start. When I read the introductory stories, I recognized mistakes that I have witnessed in my past experience and some that I made myself. It was a fascinating sequence of "look at this mess!", "Here is what you shouldn't do", "It happens when ...", and "this is what you should do".
The more I read, the more I wanted to read. And after a few chapters, a pattern appeared among the Antipatterns. The stories are not a casual collection of database mistakes. There is a thread. Most of the stories tell you what happens when you violate the relational theory principles, and the best practice solutions focus on how to apply relational principles in real life.
The relationship between the horror stories and the relational database theory becomes apparent when you get to the appendix. In other books, you can often skip the appendixes as a reminder of something that you know already. Not here. If you skip this one, you will miss a sort of Ellery Queen ending, where the detective puts together all the pieces of the mystery for the amazed audience.
I feel I would do a disservice to Bill if I revealed more about the book. I may have already spoiled some of the surprise by disclosing the inner structure of the book. But certainly I won't give away any of the juicy stories that make this book an invaluable tool for every database professional.
I can only say this. When I read a technical book, I usually find something wrong, or debatable, or some technical solution that I could improve upon. Not in this book. I completely agree with the theory and the practice that is suggested from start to finish. My QA ego suffers at the idea of not having found anything wrong, but this slight disappointment is more than compensated by the pleasure of reading such a beautiful book. Well done, Bill! I am already queuing to buy your next one!
6 comments:
Yeah, its a really good book.
However, when I finished reading it I was like "where was this book 3 years ago"
Is the link to the book broken? I get a site-not-found error.
@Baron,
The
link works fine using several browsers with two different boxes.
I find it astounding, and a Good Thing, that a MySql person would say this. From my experience, MySql devotees treat it as it is (and was intended from the start): simply a SQL parser fronting a file system, just so they can claim the Bling of RDBMS (without having to think too hard about the Relational part). How did you manage?
Most of the stories tell you what happens when you violate the relational theory principles, and the best practice solutions focus on how to apply relational principles in real life.
The relationship between the horror stories and the relational database theory becomes apparent when you get to the appendix.
@Robert Young:
a SQL parser fronting a file system?
I think your biological clock is 10 years behind. Please adjust to the 21st century. Ask major web sites running on MySQL, such as Facebook, if they agree with your statement.
@datacharmer:
I gather you mean InnoDB. I've seen no evidence that it's the predominant engine. Certainly, the MySql folk I have known, have taken the attitude that all that transactional stuff *belongs* in application code; which is MySql's heritage. If you know of a reliable survey showing the %-ages for each of the engines, I'd sure like to see it. (Facebook, yes; but who else?) My sense is that MyISAM is near to 90%, while InnoDB is near to 10%. I would fully expect that for the mass of lone web coders, it's 100% MyISAM; while for the Facebook's it's near 50%. By count (user or server or application), I expect MyISAM to be way ahead. And Mysql/MyISAM really is little more than a SQL parser fronting a file system; looks quite dBaseII.
I have nothing against MySql, except that I had to deal with it and coder folk who were overly enamoured of it in 3.X days. As a Relationalist, it was annoying to listen to coders extol the virtues of writing web apps to the same semantics as COBOL/VSAM. Been there, done that.
Since it's better documented overall, I'd rather that MySql be the OS (sort of, and all the Open Core and Oracle stuff) database of choice among database geeks. But PostgreSQL is.
Post a Comment