Book Review: The Art of SQL

You don't need to look hard to find commentary on the boundaries between blogging and 'real' (for which you should probably read 'print') journalism. It's not something I spend much time thinking about usually because I see blogging as a few random current thoughts (or belly-aching) and don't feel I have a responsibility to anyone for what I write. If it's complete rubbish, someone will pull me up on it and I'll correct it. I certainly don't put much thought into the quality of the writing because it's informal chat and I think that should be obvious to readers.

Then, occasionally, I realise how important it is to apply certain standards to what I write here, particularly if I'm reviewing someone else's work, and one of the most important qualities is honesty, even at the expense of popularity or friendship.

I'll declare up-front that one of the co-authors of this book is a good friend of mine, Peter Robson. Peter has discussed this book with me intermittently over the past 18 months or so and I was chuffed when he popped a free copy round to my house a couple of weeks ago. I was expecting it to be pretty good. Stephane Faroult is the primary author and Peter is (only) a 'with Peter Robson' but Peter earned my respect for his views long ago so his involvement was a good sign. I've heard great things about Stephane too.

Sadly, I think this is a poor book and reading it has been an extremely annoying experience. In fact, it's been so irritating that I've stopped at page 112 out of about 330 because I have more valuable uses for my time. It's important for me to emphasise that I've based this review on a third of the book, even though I can see there might be some interesting material coming up in the next few chapters. I promised Peter I'd give it my best shot, but I feel I'm wasting my time. So, what's my problem with it?

Let me start off with the positive aspects. Most of the Oracle books that I've disliked in the past have been technically inaccurate. Given the free availability of largely accurate and readable vendor documentation, it's unreasonable to expect me to pay extra for a book that is wrong. Then again, I have to accept that I've said stupid or wrong things in the past that were documented correctly, but if a book contains numerous errors, that would be my primary reason for shelving it early. I can't say I've found any blatant inaccuracies in this book. A couple of areas of minor disagreement possibly, but the authors clearly understand the subject well.

They also understand the important fundamentals of solid relational database design and demonstrate a good approach to problem solving. In fact, if I was looking for a consultant to help me implement an important new database system, I would have no hesitation in approaching the authors. While reading the book I had a constant feeling of 'Yes, I know exactly what you mean. Good point.' There's a lot of hard-earned experience behind this book.

I think the sentences are well written in the main, but it's very difficult to follow. If that seems like a contradiction, hopefully it will become clearer later in this review.

Now on to the negatives.

Most active members of the online Oracle community will be aware of the efforts of people like Kyte, Lewis and others for everyone to base their material on test cases, for various reasons. What this book reminded me was how important test cases, or rather examples, are to learning. While reading this, I often thought, 'Yes, I know what you mean, but why don't you *show* me instead of describing it to me? It's too hard to follow and takes too long this way'. I raised this with Peter and he suggested my reaction may be based on my experience level, but I think that reading this would have been worse if I didn't know the subject. There are long discussions on topics during which I would feel, 'Thank goodness I know this subject already because otherwise I would be totally lost'. Think of the subject - The Art of SQL. Doesn't that seem like a perfect opportunity for numerous examples of different ways of writing the same SQL statement, showing which is the best, and why? In the first 37 pages there are two SQL statements, neither of them very significant.

Instead there is page, after page, after page ... of opinion. Frankly, I don't care if the authors have interesting opinions based on years of experience. To me, the purpose of a book is for them to communicate that experience to *me*. If they can't communicate it to the reader, so the reader's knowledge grows, then what's the point of the book? Reading this book hasn't taught me anything. Is that because I know everything in the book? It might be, but when I'm reading a book about Oracle I always have one eye on how well things are explained. Maybe I want to steal the ideas or maybe I'll recommend this book for others to read. I wouldn't wish this book on anyone who is trying to improve their SQL skills.

There are far too many assumptions about prior knowledge. It's as though the author was writing entirely from his own perspective, without thinking about the reader. Maybe it assumes a certain level of experience and I'm missing the point? Well, I have a lot of experience and I didn't find anything that was very interesting or new in the book, so I assume it's not aimed at me. In fact, if I had to pick the most frustrating aspect of this book, it's that so many subjects are mentioned in passing and then cast aside without adequate explanation. i.e. In what I suspect is an attempt to pitch the book at a technically competent audience ('no need to explain that, they'll understand it') the book is very thin on technical substance of any kind. The result is far too abstract.

Despite there being nothing intellectually challenging here, I found it a very difficult read. Reading continuous text describing a language and a methodology with no illustrations is challenging, to say the least. If I compare it to Chris Date's 'Database in Depth' book - that dealt in very fundamental, very complex subjects and yet was much more readable because they were illustrated and not just discussed.

It's like trying to learn how to bake a cake without having a recipe or even a list of ingredients. All that's here is a description of how tasty cakes are; that it's important that they rise and that you can have different toppings. All of which may be true, but are of negligible value when it's time to bake one of your own. I'm not a fan of so-called 'Cookbooks' either, because they just give me examples and don't really teach me the fundamentals. However, even though I don't want fully-formed recipes, I do want someone to show me how to use a whisk properly. (Okay, I've done the cake thing to death now)

If I had to read 5 or 6 pages of this material in a blog format, I might recommend it wholeheartedly as an opinion piece. I agree with many of the opinions it contains, in fact. As it stands, though, I can't think of a single colleague or course student I've come across that would extract much that was useful from this. Which is a shame, but true.

I've got some good news. You don't even have to trust my opinion here - have a look through the sample chapter, which I should warn you is easily my favourite and might make this review seem churlish. If you enjoy that, you might well enjoy the book, but it's not for me.

If anyone does have a positive opinion of this book, I'm desperate to see your comments because maybe I've missed the point completely.