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

Personal Opinion

[Cinnibar CP]

As pretty much the local DBA-by-default among the developers here, I would say that having this manual, or an earlier edition similar to it, in the hands of the average programmer is invaluable. It gives them the basics of SQL theory across the multiple databases we work with and reduces the number of SQL-related questions I have to deal with.

For DBAs and advanced SQL programmers, however, I would recommend database-specific manuals that give greater insight than an overview text such as this, as this type of manual is unavoidably poor in the more important aspects of query optimization. Jack of all trades and master of none, as the case usually is.

Decent review, BTW (+1 INTERESTING, article moderation)

Glad they emphasis SQL-92

[pmancini]

SQL-92 has much better syntax than SQL-89. I just wish more of it was implemented. MS SQL-Server actually does a better job of it than even Oracle. Compare

Select A.*
From A,B
Where A.MayorName is not null
and A.CityID = B.CityID
and B.TaxRate > 5

vs.

Select A.*
From A JOIN B
ON (A.CityID = B.CityID)
Where A.MayorName is not null
and B.TaxRate > 5

The major difference is that the join is explicityly removed from the filtering done in the where cluase. This makes queries much easier to read. Queries can get extreamly complex and when you have something like 6 joins you will soon appreciate the new syntax.

This book sounds interesting so I will be checking it out!

--Peter

SQL Security

[mrkitty]

www.cgisecurity.com/lib Has some good papers on sql security.

Another good book

[Giant Robot]

The only deadtree book I've read on SQL is:

A First Course in Database Systems (2nd Edition)
- Jeffrey D. Ullman, Jennifer D. Widom

I found that it covers almost everything I needed, with a no-nonsense approach (no "CheckPoints", long pointless blurbs, or long code listings).

Although written for the academic, it didn't stop me from reading mostly the second half of the book first (the SQL stuff), and reading some theory when I wanted to.

The SQL it covers is pretty standard stuff that works with most databases (except for MySQL at the time I read it, some ACID principles couldn't apply). The specific details for each databases can be picked up by reading online docs.

If you visit SE-asia, check out their bookstores where you can find tons of "mainland china" editions of these classics that cost a tenth of the price as the real deal.

MySQL again

[fm6]

I don't want to start the "is MySQL a real RDBMS" debate again. Well, maybe. Anyway, it seems a little strange for a discussion of advanced SQL to center around MySQL. The only serious defense I've heard for MySQL is that it handles very simple queries more quickly than other engines. If you're a serious doing a database app that requires you to think about normalization, you probably need a database that's smart enough to optimize a complicated query.

Re:SQL Limitations ?

[reemul]

Not such a good example - you can model that with just three tables. One each for types A, B, C, and add an "owned by" column to the B and C tables. It's many-to-many relationships that need separate tables to map out how items interrelate, a simple "is owned by/child of" just needs a column.

Business logic should be separate from the database, with triggers and stored procedures used primarily for data integrity issues. (Which is why the poor-to-nonexistent support for transactions and foreign key relationships make MySQL a sad also-ran for many purposes compared to the expensive proprietary options. But I still hope...) You can get some significant performance benefits to putting some often re-used procedures into the database, but that doesn't make it a best practice for all circumstances. It's overused by both lazy front-end programmers who can't be depended upon to validate the input they are accepting and bored DBAs who are trying to look busy. And such items are some of the least portable code you can write for different database systems, whereas table creation and select/insert/update commands work pretty much anywhere. Doesn't mean SQL is perfect, but if your problem comes from trying to get it to do things that properly should be done somewhere else, the failure is in the design, not SQL.

Hands on, limits of

[fm6]

Get a copy of whatever database you're going to use....Next, look at a database that someone else has written and attempt to manipulate the data through queries.

I suspect most database programmers learn that way. Which is actually a bad thing. Not that hands-on experience isn't important. But a lot of databases seemed to be designed by folks ignorant of the most basic concepts of relational theory. Many such programmers could stand to do a little reading. If Practical SQL Handbook is a decent mixture of theory and practice (I'm certainly gonna give it a look), it's probably sometime all those self-taught database designers should be reading.

Why Sybase?

[puppetman]

Closed source, proprietary.

Why not Postgres 7.2 for the Linux crowd, and Firebird (Open Source version of Borland's Interbase db) for the Windows crowd.

Lots of graphical tools available, and not that difficult to set up (compared to Oracle, anyway).

Both implement all features that a modern relational database are supposed to support.

Re:Why Mods Suck?

[stoolpigeon]

I don't complain about moderation much but sometimes you can only take so much.

I would love to here from whoever moderated my post as Flamebait and have them explain some reason for that. There's nothing I said that isn't accurate and parts of it are posted all over this thread.

I guess I committed the cardinal sin of posting something that did not toe the party line. How freaking pathetic.

I like the moderation system and I like to moderate- but some times I just get pissed when some idiot who knows absolutely nothing mods someone down.

I think modding down should burn 2 points and modding someone up should burn 1. Too many people are way too free w/off topic, redundant, troll, etc.

So to the faceless, ignorant moderator of my post let me just say - You Suck.

(yeah - its friday I've got some time on my hands and I do feel better now. That's worth a little karma)

.