Kindle Cloud Readerを使い、ブラウザですぐに読むことができます。
携帯電話のカメラを使用する - 以下のコードをスキャンし、Kindleアプリをダウンロードしてください。
Joe Celko's SQL Programming Style (The Morgan Kaufmann Series in Data Management Systems) ペーパーバック – イラスト付き, 2005/4/17
― SQL-Server-Performance.com, August 17, 2006
- 出版社 : Morgan Kaufmann; 第1版 (2005/4/17)
- 発売日 : 2005/4/17
- 言語 : 英語
- ペーパーバック : 240ページ
- ISBN-10 : 0120887975
- ISBN-13 : 978-0120887972
- 寸法 : 19.05 x 1.4 x 23.5 cm
- Amazon 売れ筋ランキング: - 482,007位洋書 (の売れ筋ランキングを見る洋書)
You have to hope that his code isn't similar!
It kinda baffles me, that 3GLs, and OO languages, have gone through so much improvement, and discussion, and learning, about best practice. and SQL practices haven't changed or got any better in half a century..
- 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.
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!
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.