Joe Celko's Thinking in Sets: Auxiliary, Temporal, and Virtual Tables in SQL (The Morgan Kaufmann Series in Data Management Systems) [Paperback]

Mr. Celko has written many books on SQL and how set theory is the basis for SQL programming. His tone has gotten more ironic as more programmers without the proper training continue to rely on various forms of cursors, loops and temporary tables to manipulate data using SQL. And with the passing of EF Codd, no one quite remember any more that relational database was built on set theory.

Celko is a purist in terms of writing one-pass SQL statement. More programmers should take the same approach. Java & C# programmers think that SQL tables are either streams or files -- holders of data inside their objects. Relational-Object mapping issues are left to Hibernate or DAO. Database tuning is left to DBAs and their tuning wizards. With 2008 server processing power, inefficient sql program are hard to detect and multi-pass SQL statements are now the norm.

It's good to read Celko and get one's mind back to the basics of relational technology. I bought this book for my SQL programming team.

TN

I have (read) copies of five earlier of Celko's books on my shelf, still I am again amazed by the cultural distance. Most of my programming life I have spent with object-oriented programming languages and associated technologies. Thus, when Celko starts the present book with a discussion of the differences between flat files and relational databases, it could hardly be more distant than if he had extolled the virtues of the gasoline engine over its steam predecessor.

Celko likes to refer to his informers as "Mr. So-and-so, working for company X" this again moves the cultural differences to the front, and I can't avoid a slight chuckle when he reverently cites "Dr. E.F. Codd" for the umpteenth time. It all decidedly feels like a tale from an imaginary 1950s. I certainly envision people in lab coats.

The tone moves from enjoyably quaint to annoying, when Celko (again and again) ridicules the many failings of database novices and sophomores. He might not realize that those who share in the joke have no need to read his book -- and that those who bought the book to learn something from it may feel a wee bit offended. After all, we are already aware that there's something we don't know yet and want to learn, there's really no need to rub it in.

So much for the atmospheric stuff. But, of course, I didn't buy this book to make me feel good, but to learn something, come rain or shine. And, yes, there is a lot useful stuff in this book. More in the bits and pieces than in some generalized approach. And by far more in line with the subtitle, "Auxiliary, Temporal and Virtual Tables in SQL" than with "Thinking in Sets", the main title. Regarding the latter, I found the most worthwhile part of the book to be the discussion of why boolean flags are bad (ch. 11, Thinking in SQL).

Celko's effort to distance the relational, set-based approach from earlier practices crops up all over the book. I had expected -- and hoped! -- that Celko would put considerably energy into comparing, contrasting, and hopefully complementing set-based thinking with current object-oriented approaches. Alas, he's completely preoccupied with his own tradition and doesn't wander into OO-land at all.

I would have been very interested in reading a knowledgable discussion of where to draw the line between procedural and set-based approaches. And, as most practical programs will employ both of these approaches, how to interface the respective parts. On the latter issue, there's not a single word in this book. The treatment of the former issue is interesting, in a twisted sense. Celko demonstrates some string processing in SQL and concedes that this would be much easier in languages such as ICON or SNOBOL, those stalwarts of 1970s era dataprocessing (does he even know Perl?). Well, why then try to abuse SQL to do something for which it is ill-suited and results in bloated code? Why anyone would want to solve Sudoku puzzles in SQL I cannot fathom, either. Celko doesn't tell, and neither does he present the whole (repetitive) code, nor explain how the set-based approach works in any sufficient detail.

The overarching mindset exemplified in this book is to push as much into the database as possible, even if it hurts at times. I don't mean to denigrade the intention, namely application-independent, consistent data storage. However, the reality in current software engineering is that a shared database is but one solution among others. For instance, SOA (Service Oriented Architecture) is specifically about connecting applications through services they provide, not by tying them to a shared database.

Celko likes to style himself in the image of Ming the Merciless. The semblance is indeed uncanny and as I hinted already, he tries to live up to the role as his author persona. Unfortunately, he doesn't seem to realize that there's one thing that can't be tolerated in an arch-villain (as well as in his henchmen and henchwomen): sloppiness. The book has more than its fair share of typos and grammatical accidents. A particularly amusing case in point -- due to his belligerent character, a deeper insight, or simply search-and-replace gone awry -- is an example that consistently refers to "martial status".

For the good parts I'd doled out 4 stars. For The many detractions I deduct 1 star.

I picked this up at a bookstore because it was the only mildly intriguing title I saw, and because I don't spend much time thinking about databases. As another reviewer mentions, there is an amusing old-school style, and a humorous example or two of SQL code tortured into doing something "right" and, of course, doing everything in the database. There are numerous typos, too, but not of the type that would put me off.

Maybe I'm not so annoyed by the suboptimal organization of the book and the scattered but useful insights as I should be. But where I found useful things, the payoff was deep. I don't mind Celko's tunnel-vision on the database. He advocates but does not evangelize his position. He knows what his chosen tools can do but betrays no hint, at least to me, of being a Golden Hammer type.

I could also care less whether Joe Celko is a hipster with cool office sneakers who twitters heartfelt one-liners on fresh tech. I know this is hard to fathom, but people over 40 are still alive and do produce useful things. I suspect Joe wears three-piece suits to the office now and always will. He also seems authentic; that goes a long way. I got a good deal of useful information from this book, but it was an uphill read at times.