Customer Rating:  
Summary: 3.5 stars: Has good stuff but very undercooked
Comment: 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.
Customer Rating:
Summary: This is the nth try to post this review
Comment: 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!
Customer Rating:
Summary: Great SQL Style Reference
Comment: This is a great reference for how to write clear, concise, and efficient SQL. If you are looking for good ideas for SQL coding standards, you will find them here.
In my career, I've seen a lot of poorly written, nearly incomprensible SQL, which is always harder to maintain. I just wish more novice SQL developers and DBAs had read this book.
Customer Rating:
Summary: I really enjoyed this book
Comment: Wading through badly written SQL is a nightmare on the best of days. Proper--and consistent--attention to capitalization, indentation, and other formatting standards makes SQL much more readable and therefore maintainable. The standards outlined in this book are for the most part very well thought-out, and a great starting point for creating a set of enterprise SQL development standards. If more SQL developers would read this book, I would have many less headaches in my day-to-day work, so I believe this is a valuable purchase.
Customer Rating:
Summary: Excellent book in excellent style
Comment: Too many database books are written by developers whose expertise is OOP and not SQL. While I don't agree with Mr. Celko on every point, keep in mind that he was on the SQL Standards Committee for 10 years. Even if you don't agree with him on every point, his level of expertise is undeniable - unless, perhaps, the questioner can provide evidence of greater knowledge and expertise.
This book is to SQL grammar and style as "The Elements of Style" by Strunk and White are to English grammar and style. Mr. Celko explains, in terms that should be easily understood, why SQL should be written in standard SQL while still allowing that there can be exceptions just as verbal communications, in any language, should follow the standard grammar of the language unless there is good reason to slip into a localized dialect.
Where one reviewer rated the book with 1 star because that reviewer disagrees with Mr. Celko on a single point of database design, his antagonistic remarks have nothing to do with the point or the value of this book.
As the editorial review states, this book is not for beginners. If you have been programming SQL for a year or more and you want to fine tune the quality of your work, this work is something you should surely read.
|
|
