Slashdot Mirror
SQL: Visual QuickStart Guide
What this book does right: The myth that it's more important for a programming book to be technically accurate than well written endures even though the opposite situation is true: A lucid explanation of a difficult concept or clever algorithm is more valuable than a bug-free implementation of same.
Consider Ken Henderson's The Guru's Guide to Transact-SQL , a book full of useful examples but so marred by the author's bloated style and disrespect for the language that I cringe every time I'm forced to read the text rather than simply lift a code snippet. Henderson even goes so far as to include an introductory section, titled "On Formality," about how he is going to split infinitives (even though their syntax is a burden for the brain to parse) and how he is going to use "data" in the singular sense (even though doing so can cause confusion) and how he considers "record," "row", and "tuple" to be interchangeable terms (even though they're not) and on and on. Readers would be aghast to find such self-exculpatory nonsense in the pages of Donald Knuth or Patrick Henry Winston. As for SQL: Visual QuickStart Guide, the author, a statistical programmer, presents each topic with a mathematician's sense of restraint and order. I've found few typos, no technical errors, and consistent use of technical terms.
Almost every aspect of SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, and DROP is covered. What distinguishes this book is that every ANSI SQL statement -- and there are hundreds of examples -- was tested on six separate DBMSes: Microsoft Access 2002, Microsoft SQL Server 2000, MySQL 4.0, PostgreSQL 7.1, Oracle 8i, and Oracle 9i (8i and 9i differ considerably in SQL-92 compliance). The examples in each section increase in depth and complexity, so you can stop reading once you've learned what you need to know. When an ANSI SQL statement doesn't work as-is on a particular DBMS, the author shows you how to fix it or offers workarounds (which is particularly useful for MySQL, whose adherence to the SQL standard is poor). These DBMS-specific fixes are given as separate "DBMS Tips" apart from the main body of text, so they don't interfere with the conceptual flow. This organization is especially useful for consultants who have difficulty keeping track of how each implementation deviates from the ANSI standard, and is superior to the alphabetical, segregated approach of O'Reilly's SQL in a Nutshell.
This book was shoehorned into the publisher's Visual QuickStart format, which, as I implied earlier, doesn't work well for procedural languages, but does work for a declarative language like SQL. A two-column layout separates examples from explanatory text. Red type highlights the relevant portions of code and results. The book is extensively cross-referenced and has an 18-page index. This layout also makes the book a good quick reference for experienced programmers. Almost all the examples use a single, sample database (so there's no need to memorize multiple schemas). The code listings and sample database are available for download.
The derivative nature of programming books makes it difficult to determine whether the author truly has mastered the material. Writing a book is a difficult task (perhaps even harder than programming) but, at the risk of exaggerating my point, I suspect that any determined, organized, and competent programmer could write any O'Reilly Nutshell book by paraphrasing existing materials. But if an author establishes his credentials early, the reader gains a sense of trust that remains throughout the entire book. In the introduction to this book, the author avoids an error that almost every other SQL-book author commits: that SQL stands for structured query language. According to ANSI (the only legitimate arbiter here), it stands for S-Q-L and nothing more. Fehily even offers an amusing explanation of why structured query language is the worst possible description of SQL. Throughout the book, the author also scatters bits of practical advice (job candidates are wise to say my-es-kyu-el, not my-sequel), beginner-friendly insights ("Although SELECT is powerful, it's not dangerous: You can't use it add, change, or delete data or database objects."), and advanced topics (optimization, concurrency control, logical data independence). It is these asides and respect for basic research, rather than swaths of expository text, that lend authority.
This book describes the effects of nulls in almost every aspect of SQL, including the interpretation of null-contaminated query results. You can no more be a competent SQL programmer without understanding nulls than you can be a competent LISP programmer without understanding recursion. Particularly useful are the discussion of three-value logic (true/false/unknown) and an algebraic derivation of how a null can cause a subquery to return an empty result unexpectedly (which has bitten me more than once).
As a wizened developer weary of hand-holding users and junior programmers through routine queries, I've found it mollifying to give away copies of this book (it's cheap) to reduce my interrupt stack.
What's Missing: Some missing items that I would have found useful:
- A glossary
- A quick syntax reference
- A chapter about statistics
- A chapter about advanced SQL "tricks"
- DB2 coverage
- Coverage of security commands (GRANT/REVOKE)
- An expanded query-optimization discussion
- Improved normalization examples
- A little more mathematical rigor in the set-theory discussion
"The myth that it's more important for a programming book to be technically accurate than well written endures even though the opposite situation is true"
So, you're saying... who cares if the code is wrong as long as you think you understand it? Personally, I'd rather have the right code.
... doesn't it end up being easier reading the documentation for the SQL products themselves? SQL is one of the few languages I would argue actually does *not* need a book. Reading a PHP/Perl book about any RDBMS using SQL would enlighten one as to the basic functionality; all further research could be done on the site of the RDBMS of choice. Yes, this would imply that they end up learning implementation specific SQL, but as long as one sticks to the "basic guidelines" found in the aforementioned books, one should be able to write fairly portable SQL, and fairly quickly.
Kind regards, Devon H. O'Dell
If you read Oracle's docs, they'll tell you to use NVL(). If you read MSFT's docs, they'll tell you to use ISNULL(). Both databases support the standard SQL function COALESCE() that does the same thing and is portable. There are other similar examples. Only use the docs that came with your database if your database is PostgreSQL. Except for backslashes within string literals, they pretty much respect the standard.
For beginners, this sounds like a good book to learn the basics of querying and allow them to begin honing their skills.
For professional (and soon-to-be professional) developers, learning STRONG SQL is a good idea. Many developers (esp. casual web devs) never take the time to get a good grasp on the language and write queries with a balance of effectiveness and efficiency.
Another good book to keep in mind (if you're serious about development) is "Database Design for Mere Mortals" by Hernandez and Getz. I'm sure it's been mentioned a few times here already.
Uh.... where did you get your DBAs? Do they understand that stored procedures offer performance benefits by reusing a stored execution plan? That stored procedures encourage code reuse just like function libraries in the procedural language of your choice? That by isolating a block of code away from being embedded in code it's much easier to put in the finnicky lock control statements that you generally don't want mucked about with by junior programmers? That by moving back to embedded SQL you are probably giving up control of locking mechanisms whatsoever? That you are quite likely moving sorting/selecting logic out to your embedding code, and away from the database engine that is much more optimized for these operations, offering advanced tools like cursors and temp tables?
If you're a programmer, you need to know how to specify what you want to feed into a stored procedure, and what you want to get out of it. If you can't write the proc yourself, you need to get someone to write it for you. Embedded SQL is a bad idea. You tie yourself to one table structure because you can't possibly change all the embedded code snippets. You miss out on debugging opportunities because you won't use PRINT statements in your sql. Etcetera, etcetera, etcetera. I don't want to do maintenance on my code either, but it IS my job after all.
You, as the instructor, could have filled in those gaps. It would be better if you didn't depend solely on the Visual Quickstart Guides. If that's all you had to work with in the course, you could have fleshed out the course more with your own instructional material and knowledge.
I teach Microsoft developer courses (MOCs). The materials are often plagued with similar issues that you find with "teach by example" systems. That's where I fill in the gaps using the whiteboard, demonstrations, online references, hand-outs, and other resources.
The most important resource that's available to students should be our own knowledge developed over the years. It should not be coming strictly from a book.