Joe Celko's SQL Programming Style (The Morgan Kaufmann Series in Data Management Systems) (英語) ペーパーバック – 2005/5/1
Kindle 端末は必要ありません。無料 Kindle アプリのいずれかをダウンロードすると、スマートフォン、タブレットPCで Kindle 本をお読みいただけます。
Are you an SQL programmer that, like many, came to SQL after learning and writing procedural or object-oriented code? Or have switched jobs to where a different brand of SQL is being used, or maybe even been told to learn SQL yourself?
If even one answer is yes, then you need this book. A "Manual of Style" for the SQL programmer, this book is a collection of heuristics and rules, tips, and tricks that will help you improve SQL programming style and proficiency, and for formatting and writing portable, readable, maintainable SQL code. Based on many years of experience consulting in SQL shops, and gathering questions and resolving his students’ SQL style issues, Joe Celko can help you become an even better SQL programmer.
- Help you write Standard SQL without an accent or a dialect that is used in another programming language or a specific flavor of SQL, code that can be maintained and used by other people.
- Enable you to give your group a coding standard for internal use, to enable programmers to use a consistent style.
- Give you the mental tools to approach a new problem with SQL as your tool, rather than another programming language - one that someone else might not know!
“Joe Celko, maybe one of the most prominent representatives of the database community these days, has written some of the best books about SQL programming in general. This book, however, is different. “SQL Programming Style doesn’t teach you how to become a better SQL developer with SQL puzzles and brainteasers. Rather, it shows you “how to work in logical and declarative terms.
― SQL-Server-Performance.com, August 17, 2006
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!
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.
but you might get just as much by hanging out on Stack Overflow in the DBA pages. It has a lot of nicely-formatted
and well-explained code.