The Practical SQL Handbook: Using SQL Variants (4th ed.)

Continuing the grand tradition of reviewing computer texts sent to us by publishers, Slashdot author chrisd has read the book The Practical SQL Handbook: Using SQL Variants and written up a review. If you are interested, read on ... The Practical SQL Handbook, 4th Edition, SQL Variant author Judith S. Bowman, Sandra L. Emerson, Marcy Darnovsky pages 512 publisher Addison Wesley rating 9 reviewer chrisd ISBN 0201703092 summary An indispensable introduction to SQL. This is probably one of the best books I've read for those new to SQL. It's the kind of book I wish I had many years ago when I was first learning about databases. The only problem is the SQL variants are not really for me, a developer uninterested in Oracle, MS-SQL, Sybase or Informix. That said, this is a minor part of the book and doesn't really detract from it, and I can even come up with any number of reasons why a developer would want to have that information. A comparative text would be useful by itself, but I think that trying to teach SQL and several SQL variants is too big a job for any one book.

The books introductory text on SQL is clear and concise. I also found its treatment of normalization to be as close to perfect as can be with one exception: It doesn't tell when you can go too far with normalization. In an introductory text this is acceptable, and perhaps wise considering what many new to relational databases consider acceptable database design.

And while the introductory chapter is great, the chapters on selects and joins is so clear and useful that I would even call it exciting. The terrific thing about this book is when you have finished reading it you should come away with a feel for how the underlying DB actually works and what it is doing to produce the data for you.

I personally found this book very useful, even though I am using MySQL for the application I'm writing. But the feature set that MySQL chooses to support will logically limit the usefulness of the this book for the MySQL user. Programmers developing for Postgres, Firebird, and others will obviously get much more out of the book and its treatments on subqueries and views than will MySQL users.

One thing that did turn me off is the inclusion of a CD-ROM. The CD has a copy of Sybase for the user to work with. I don't need to explain that the internet is a superior place to put such things. That said, at least it wasn't glued to the back cover (a pet peeve) and was instead bound into the book like a magazine reply card. Many publishers perceive that they can charge more for a book that has a CD, but I just find it annoying and wasteful. But that's hardly a reason not to buy this book and place it on your bookshelf in a prominent position, not on the bottom ghetto shelves next to the stack of paper for your printer.

In short, those looking for an book about SQL, that won't teach them bad habits would be well served by this book (and likely by its sister book, The Practical SQL Handbook: Using Structured Query Language by the same authors) and those who think they know SQL will find it a useful text to have handy as well.

You can purchase The Practical SQL Handbook: Using SQL Variants from bn.com. Slashdot welcomes readers' book reviews -- to submit yours, read the book review guidelines, then visit the submission page.

Comments

Well-done book

[lseltzer]

I read an earlier edition and have a very high opinion of it. It's not an intro to database programming, but it will get you from nothing to very far into SQL.

Very controversial book

[PhysicsGenius]

I found this book very helpful in building the database I'm working on but I was surprised at the vehemence the author displayed when discussing MySQL and PostgreSQL. I use those two workhorses all the time but the author said that they were "only good for crappy websites and e-commerce wannabees". I thought he was referring to the well-known stability issues but later on he goes into great detail on how each of them has broken the SQL standard pretty badly.

It came as news to me, but the author is a SQL god so I guess it must be true.

Keep your pet hates to yourself

[gazbo]

I'd rather it came on a CD with the book. Why? Because I don't want to spend x hours downloading shite just so that you don't see a CD in your copy. And I've got DSL - just imagine what it would be like for those on dial up.

Honestly, that is the most pathetic argument I've ever heard in a review - it would be more reasonable if you had said "they didn't provide a CD but made it available for download. This will be a major irritation for modem users, and there is no reason why they couldn't have shipped it with the book."

SQL Limitations ?

[smak]

I'm just getting into SQL myself - at least I've got perl talking to a mysql database :)

During a web-search for help with SQL, I came across a discussion, which said that SQL had many limitations (I don't have the link anymore.)

I've found SQL reasonably powerful so far, but obviously I'm new to this stuff.

Can anybody point out the areas that SQL is lacking in ? (and maybe where new progress is being made.)

Just interested.
Cheers.

Re:SQL Limitations ?

[Entrope]

SQL is particularly weak if you have definite but flexible hierarchy -- for example, say that you have relations like this between objects:
Obj1 (type A) "owns" Obj2 (type B) and Obj3 (type C)
Obj2 (type B) "owns" Obj4 (type C)
There is no particularly good way to model this relationship in SQL; you need at least four tables (one to establish ownership relations and act as object identifiers, and three to define the traits for types A, B and C) where you would ideally want only three.

Another weakness is when implementing "business logic" -- rules that define whether or not particular changes are allowed, or what else must change to keep things consistent. In the past (I believe SQL99 improves this, but is not widely supported yet), there was no standard for defining smart triggers, constraints or stored procedures, and some database systems did not support such things at all. One common solution to this problem is to have a layer of code in front of the database that performs all of the transactions and reports business logic violations to its clients -- the classic three-layer database system, but not as efficient or clean as if the business logic could be handled by the database system itself.

There are some other application-specific weaknesses; for example, a full inverse text index cannot be stored both efficiently and portably in SQL. This has impact on things like DNA sequencing as well as text searches.

On-line analytical processing is also somewhat limited within the standard; this partly goes back to the lack of a standard trigger language, and partly to the traditional table/row model of a SQL database.

SQL is a very powerful and very useful standard, and its existence as a standard has done an incredible amount of good. It does not solve every problem -- but given how complex the standard already is (and has to be), that may be a good thing.

Re:That's because

[edhall]

SQL != SEQUEL

Although SQL is largely derived from it, SEQUEL was the query language of IBM's first Relational Data Base Management System, System/R, dating back to the mid-1970's. (IBM's second --and current -- RDBMS was creatively named DB2.) So pedantic old farts like me are careful to distinguish between the two and pronounce SQL as ess kyoo ell to avoid confusing it with its more primitive predecessor, SEQUEL (though it's not like there is any real chance of confusion these days).

-Ed