151 of 170 people found the following review helpful:
3.0 out of 5 stars
I'm a little underwhelmed..., January 11, 2002
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.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
31 of 32 people found the following review helpful:
5.0 out of 5 stars
Advanced SQL Programming!!!!, February 18, 1999
By A Customer
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.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
![[Start the discussion]](http://g-ecx.images-amazon.com/images/G/01/x-locale/communities/discussion_boards/start-new-discussion-sec._V192250339_.gif){kind=small}
