Customer Reviews

Joe Celko's SQL for Smarties: Advanced SQL Programming (The Morgan Kaufmann series in data management systems)

5 star:		(31)
4 star:		(14)
3 star:		(8)
2 star:		(4)
1 star:		(2)

 

 

First of all, I couldn't recommend this book for beginners. It is, however, PERFECT for the SQL programmer with some experience who is looking to take his/her SQL abilities to the next level. There are great pure SQL solutions for problems that many programmers think must be done outside of SQL in a host language. One of the most important lessons from the book is this: think in terms of sets and set theory instead of in terms of columns and rows. Lots of other great info though. Be warned: the examples are all written in the SQL-92 ANSI standard. Examples will have to be modified if your vendor-specific implementation of SQL doesn't follow the standard precisely. Kudos to Joe.

Not so much unimpressed at Joe's knowledge, which is impressive indeed: the book reads a lot more like a teaching text than most technical books.

But there are things in here which may lead astray some who have already done things that Joe advises strongly against. I will concentrate on one example: In chapter 3 "Numeric Data in SQL", under the heading "Generator Functions" (e.g., IDENTITY, AUTO_INCREMENT) we get this doozy: "This is a horrible, nonstandard, nonrelational proprietary extension that should be avoided whenever possible". Just a statement, no reason whatsoever provided for it, because I guess he assumes we know some "math rule" or something behind why it is such a bad idea. Now, we must think for a minute why one uses such a data column. In my own case, I have a table called Parts that contains parts from several different companies. So, I guess Joe would have me make a composite primary key from PN and CompanyID. But, wait a minute, that complicates matters when I need to have a foreign key reference to the Parts table, and, oh by the way, just what is CompanyID anyway, maybe some other composite key, or some goofy "rule-based" (can you say TRIBAL KNOWLEDGE) thing? You can't seriously believe that "ALFKI" is a better key than,say, 33. What happens when I get a new customer named "Alfred Kiplinger", and have to change the "rule" that I came up with for defining the primary key? See the problem? You're not going to remember the ID anyway, because the rule will be broken at some point. I also happen to think that a part number (to give one example) should be changeable. So, I don't make PN the primary key (because you should NEVER change a PK), I simply have the database generate one for me. What am I missing here? It was not explained to me in this book, it was just a blanket statement of preference, put across like a hard and fast rule.

But then come the contradictions. In the very next chapter on temporal data types, we get a very long paragraph on "key generators" and how they need to be designed to eliminate or minimize identical keys (I kid ye not!). He talks about elaborate hashing algorithms, the server system clock, random number generators, and how pseudorandom numbers are not usually a problem since the cycle size can be "hundreds of thousands or even millions of numbers". Huh? Amazon has 50,000,000 customers! I'm sure they wouldn't be too happy if "only" every millionth one had the same id! No mention in this entire section on GUID or UNIQUEIDENTIFIER, which won't repeat forever in the known universe!

Then there is seeming randomness to the topics introduced. I think I work with a guy that's a lot like Joe, but man, can it be hard to follow the "why" of what he is talking about! I usually figure it out about two days later when I'm sitting at my desk working on something completely different. Here's one example: We go from an incredibly long section on Domain Key Normal Form, with all of its calculus functional dependency stuff ("A determines B, therefore if CA = B, &c, &c, &c....."), to a paragraph right after this about normalization, and how a Students table should not have "Student data and also bowling scores". But come on, that's DB101, not Math335!

Bottom Line: The reason I gave three stars to this book is that I think I misread its intention. I believed it to be a book for someone who knew SQL, and wanted to become more advanced in SQL. Now that I ponder the title, however, I believe that it means "OK, here's a book for you scientific math types out there who want to apply your math degree to learn SQL", i.e., SQL for smarties, not for non-degreed dummies like myself. That, to me, is exactly how the book is written, and it probably succeeds against that yardstick.

I have been programming database applications since 1984. I started using SQL in 1989. Since that time, I thought I had mastered SQL. Well ... I was wrong. Joe's book helps pin point the finer things concerning SQL ... how it really works. Anyone who is an ADVANCED user of SQL will find this book full of the little things that all most all developers will overlook. For example, how does a SQL statement really execute (pg 174 to 181) explains this in great detail. Many advanced developers are not just satisfied with knowing how to do something; but, want to know every little detail about how something really works. I found the chapters on normalization and Armstrong's Axioms to be the most useful concept in the entire book. Database design concepts are critical in performing a good, solid, and efficient query and this chapter brings it out very well. I have found this book to be my only source for advanced SQL concepts (besides Joe's puzzle book...). Good job ... and thanks.

My first problem with this book is its errors. ... there must be one on every page. There's way, way too many typos for a book like this. Half the examples won't work without corrections.

My second problem is that the book is rife with academic exercises that have little application in the real world. Code that uses cross joins will not perform well against even moderately sized data sets. Most of the examples make great magazine pieces, but fall short of anything that's actually useful in the real world.

Third, Celko likes to use syntax that has been implemented on paper only. For example, he uses set operations that no vendor has yet implemented (and probably never will since they became part of the ANSI standard years ago). A fair number of the examples in this book use code that will not run on any DBMS - even after you clean up the typos....

In sum, this book was a good idea, it's just a poor implementation. Celko needs to do some real DBA work and write from that experience. Saying "different DBMSs implement things differently - see your vendor docs" on every other page doesn't help anyone.

I cannot work without this book. Stuck with a poor database structure and huge volumes of data, I have had to explore every trick of the trade. Few computer books in general provide information that is accurate, helpful, and not repetitive of manuals and online material that is already available to you. This book is of exceptional value. Someone swiped mine and believe me, I must have another copy. How many of the computer books you have purchased get that kind of respect?

Warning: Beginners may need another book and it is not a replacement for your SQL vendor specific reference.

Joe Celko knows SQL. He may make some typos as a writer but make no mistake... this guy knows what he's talking about. He knows the language and the mechanics of the major database engines. But more importantly, he understands the logic of it all. Some of his SQL moves are simply brilliant.

I develop enterprise applications and am called upon now and then to create some very challenging SQL. Celko has bailed me out several times. I have the book as a reference source right next to my database reference manuals. He is full of ideas and often times I am looking for an idea, not a recipe.

This is a book for people who have a good knowledge of SQL. It will stimulate your thinking and programming. It isn't a book for beginners. In the right hands, SQL for Smarties will really add some sizzle to your SQL coding.

Brianne Elizabeth Corbett - IBM Global Services

This is a new edition which expands the programming tips from the first edition and removes the theoretical content (theory is now covered in DATA & DATABASES).

If you are conversant with SQL, this is a great book to buy. This book has all kinds of advice for finessing SQL for power users. It is the only advanced SQL book of which I am aware.

This book has been marvellous for me. I've been dealing with large ERP databases for the last two years now and Joe has really helped me tune and optimise my SQL to get the best out of the SQL-92 standard (and make my queries run at least 50% faster!) I believe that this book is a MUST for anyone who takes their SQL seriously; whether you're a student, a developer or a systems analyst, you can be sure to learn a lot from here and squirm at all the SQL pitfalls you've been digging yourself into. Great stuff.

Being a professional Database Administrator using Ingres, I wanted a good SQL reference book and I found it. This book does not teach you SQL it is designed for those who are already familiar with basic conventions; what it does do is to highlight areas where you could improve the efficiency of the code you write. This resides on my desk permanently and should be treated as a reference bible rather than a tutorial. The gems it contains cannot be absorded at first reading...you will refer to it again and again. A fine book and a great buy.