Updates
Latest Tweet
What's New?
Check out for latest innovation, a computer based training video collection
Like this Page
Joe Celko's SQL Programming Style Review by John Bonavia
This is the nth try to post this review
If this review finally goes in, I shall be pleased but surprised, There is something wrong with Amazon's linking. I have spoken to support and they don't know what it is. Anyway...
This is a mixed bag, but mostly very good. Lots of excellent information about different versions of SQL vs. standards, and fascinating excursions into the underpinnings of coding systems, measurements, scales, ratios, etc. We should all be a lot more aware of the work that has been done and codified in many international standards. Apart from anything else, it would save people from re-inventing so many wheels - and making some of them square!
There is an excellent and much-needed stress on the need to use relational thinking when you are working in the SQL environment, with the focus on natural keys and set-oriented processing. He rightly decries the use of "external locator" keys (which most of us call "surrogate" keys, though he defines that term differently) - anyway, basically the "Identity" type. He is perhaps a little too extreme in pretty much absolutely outlawing them, but I agree with the general principle. They are an expedient pushed by people who don't understand relational design. Natural keys are much better. (But I have to agree with another reviewer that the SSN is problematic. Coming to the US from Canada, I couldn't believe the SSN was not a check-digited number, unlike the Canadian SIN, or any credit card number, or banking ABA's. I guess the age of the system was one issue. But the result, anyway, is that duplicate SSNs exist and that they are frequently invented or stolen.)
As a self-described "old fart" he castigates the design errors that may be committed by those (like me!) who grew up in the age of punched cards and magnetic tape. But surely few current database designers have ever seen a punched card, and rarely encounter a good old sequential fixed-length-record file, let alone a mag tape. The model that leads them astray these days is not the sequential file, but the Excel spreadsheet! Time and again I see HORRIBLE designs, violating all the normal forms from 1 to 3 and beyond, based on the columns of an Excel spreadsheet. Another factor is the lack of relational training - how many people have read Codd or Date? and the harm done by the early PC databases that were just a kind of disorganized dumping-ground for data, draining meaning from the term "database."
Some of his mandates are perhaps a little too absolute "Don't use cursors" - well, 99% of the time, very true. You should be thinking sets, not serial access. But there are a few occasions where a cursor can be a useful weapon in your armory and can even execute faster than a set manipulation. Not many, but a few - beyond the outlying cases he describes. Similarly with triggers - yes, generally DRI is far preferable (if your DBMS supports it). But if you want customized transaction audit capture, triggers are the natural way to go.
A few beefs:
There's a sprinkling of typos, and I did spot one actual error: on p 114, he presents "WHERE a = b + 2" as the alternative to "WHERE a + 2 = b - 4." Oops! Obviously the valid alternative is "WHERE a = b - 6."
The discussion of Camel Case is too limited: there are a lot of variations and his definition is at odds with the widely used Microsoft definition, which would have been worth mentioning. For MS, camel case is like "thisCase" and Celko's camel case, "ThisCase," is called Pascal case.
I found his advice on formatting and display of code sometimes odd. Often when he showed example A and then "see how example B is more readable " - I thought example A was clearer! He refers to studies on visual perception, eye movement, etc., but I am not sure that such studies done in the context of reading normal prose are valid for SQL, or other programming-type text. Comprehension likely occurs in different stages or chunks.
Also, surely Hungarian notation is found in strongly-typed, not weakly-typed, languages. In a weakly-typed language like REXX, a variable can be a string one minute, an integer the next. What prefix can you use? Whereas in VB, for instance, up to version 6, MS recommended prefixes to remind the programmer of the fixed type as defined, so he would not be tempted to write "intAccountID = "New Customer" or suchlike.[...]
Summary? Well, OK, I've listed a few problems, but overall, get this and study it - there's lots of fascinating and rewarding material, from someone who has been working in this field a long time and has gone very deeply into many aspects of it. Many of the SQL examples will really stretch your brain - his other books do that too!