Joe Celko's SQL Programming Style (The Morgan Kaufmann Series in Data Management Systems) [ペーパーバック]

Style guides tend to be heuristics of understanding a hard-to-define -- consequently hard to defend -- criteria that will make your design effective. Strunk's "Elements of Style" would be an exemplary definition of a style guide. With all style guides, however, you can follow them religiously and still end up with an execrable book or living room.

Mr. Celko spends remarkably little time with style formatting, although he does delineate what constitutes readable and maintainable SQL code. Where the book finds its utmost utility is in the consistent and increasing reinforcement of thinking in sets. SQL is not about transforming data (although you can); SQL is about properly storing data, and then being able to find it again. Simple enough, but all-too-easy to get wrong.

The first two chapters talk about naming and actual SQL style. This is primarily what I'd expected, but Mr. Celko isn't about to let me off that easily. In discussing naming, he brings international standards into the mix. Right away, the standard of my existing SQL code falls away under this level of scrutiny. Throughout the book, Mr. Celko is bringing up a data discipine I have long-suspected existed but honestly never sought to embrace. Why should I develop a data model that adheres to standards, if mine will be the only model in the company even attempting it?

Therein lays the problem with this book: it can make a reader uncomfortable. Mr. Celko is writing about SQL and, more importantly, the data it will describe and manipulate, in far more depth and with far more rigor than I've seen elsewhere. He has an entire chapter on encoding data, another on scales used to measure data. Nowhere else will such treatment be gathered in one place, in the context of using SQL. Moreover, his conclusions are backed by years of experience *and* impressive references to back him. The bibliography will surely cause me to invest in yet more books.

Of course, the book can be dry in spots. Encoding data properly is important, but it's not as entertaining as seeing his effective SQL examples put to work. I think the balance between showing data as it is displayed and explaining the theory of the encoding (or modeling, or selection) is tricky to achieve, but I don't believe it ever broke down. The *density* of the book is striking; going into a 195-page book, you don't readily expect to re-read the same page three times to grasp something, but you must. At some point in the book, you will encounter an aspect of SQL development you've never come close to mastering, and it will give you pause. Take notes, work it out, and dig deeper. It'll be worth it.

Could I recommend this to newcomers to SQL programming? Qualified yes; you need to discipline yourself to work through much of it if you lack the experience in what's being presented. The book would make an excellent two-semester course in database development, one I suspect many would enjoy more than the typical relational database classes taught today.

Mr. Celko has again delivered an essential text on SQL, and it would serve as a springboard for a thorough introduction to all things data.

Fred

This is not the first book I have read from Joe Celko. I appreciate very much his clear and concise style and the examples he provides, always meaningful and to the point. This book is not the exception and it completely fulfilled my expectations. In a very scholarly way (rule / rationale / examples / exceptions) Mr. Celko covers all the aspects that I could expect from a "programming style" book: layout, naming, SQL do's and don'ts, guidelines about views, triggers, stored-procedures, checks on columns, etc. He also provides a list of resources regarding standards (Military, ANSI, ISO, Industry) that I found very useful. I can highly recommend this book to any experienced or inexperienced person that deals with SQL (developer, DBA or even a data modeler)

My only criticism would be regarding a few unkind remarks he wrote about "newbies". I do not deny the value of showing examples of bad SQL coding followed by a better way of doing it, but there are ways to present them. I wouldn't be happy to see my name in a sentence like "As an example of a horrible misuse of SQL, [name of the guilty] posted a procedure ...".

It was also not very nice the way in which Mr. Celko introduced the Basic Software Engineering section: "With some embarrassment, I will now give what should have been covered in a freshman course". If a "newbie" is reading this book to gain some knowledge, he or she doesn't deserve the criticism. They know they are inexperienced and they are trying to improve. And the sloppy programmers, who may deserve such a criticism, they are not going to read a book like this anyway. Don't you think?

I'll expand on that when I have time; but for now, real quick:
PROs:

- As usual for Celko's books, you get this feeling of conversing with a knowledgeable and overall very likeable individual with a good sense of humour (he got me laughing on page 2, see his comments on the making of fine furniture).

- Good justifications are given for many rules of thumb that, as of now, you're likely to be adhering to on faith.

- A number of unobvious, sharp, mind-stretching tidbits (an ever-present feature of Celko books).

- Very good bibliography. Celko is not a "narrow specialist": reading pointers he gives are varied and very interesting. Also, links to a lot of net material. Great.

- He writes simply.

-----------------------

CONTRA, the one and only problem: the book appears to be written in a terrible hurry, which is manifested by the following occurrences (not exhaustively):

- Sometimes the author has something to say, but does not say it intelligibly (e.g., section 1.2.7)

- Sometimes he doesn't have anything to say, but gibbers on anyway (e.g., section 3.15)

- Sometimes he belabours the obvious or maybe even spurious: for example, there's too much of this "unlearn OO to understand SQL". One doesn't need to unlearn what one knows to learn something he doesn't; there's no clear-cut distinction: for example, operating on STL collections is very set-like, quite SQL'ish actually: you provide a predicate and it's then applied internally in a set-scoped operation. Matlab is very similar. BLAS is very similar. Fortran is similar. Iow, thinking in sets is an important thing to point to -- once; but after that it's beating a dead horse; move on already. Especially since it isn't really as black-and-white as the author suggests.

(4) The book is very inadequately indexed: index is very small; nothing can be found. What's SQL/PSM? I don't think it's been defined anywhere, but perhaps I missed it; off to index I go... and find nothing there. How nice. I mean, come on -- a five-page index in a technical book?

(5) Dropping French. Is it really necessary? "Sistemé International d'units", OK.

There's more stuff to talk about, both good and bad; but I've no time to write it up right now. So, finally: is it a worthy book?

Well, the book is flawed but not useless by any means. It's not a must read, but if you got a few discretionary bucks and a bit of free time, it's worth reading. I've learned a few interesting things here; ~1/3rd of the reading has been pleasant: in addition to knowing a lot of stuff, DB-related and beyond, Celko's got a real good sense of humour and a gift of gab. Were this book a brochure one-third its current size sold for five bucks, I'd give it five stars. OK, ten bucks.