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
Bookpool has it for $14.50
...make sure you pick up a cross-platform tool for working with SQL. SQL Server is particularily hard to use in a cross-platform way, but thanks to the jTDS and FreeTDS projects, we now have drivers.
Linux and Mac OS X users, unite! Or untie. Or something...
Javascript + Nintendo DSi = DSiCade
This is how I first cut my teeth in SQL, but I only developed 'real' skills when I started writing SAS code on a huge solaris system when I worked for a bank.
It's mostly complient to 92, and working towards 99. Check here for it's current "Bugs" status.
The only noted "bug" in it's SQL-92 complience is that whitespace gets stripped out at the end of VARCHAR types. Though a bug, there are other databases that do this as well. MySQL is working on becoming SQL-99 complient and have already started to look at (hypothetically) the changes that are to be made for SQL-2003 compliance.
"Time is long and life is short, so begin to live while you still can." -EV
Barnes and Noble has it for $21.99 while Amazon has it for $15.39 (unless they have some kind of dinamic pricing and not everybody sees the same price).
Plus, there is also MySQL: Visual QuickStart Guide.
This paid my last vacation, it mi
Yeah, you could run my company out of employee id's fairly quickly that way.
Also, SELECT * is widely overused, and in the wrong contect, can bring DB's/networks to their knees. It should be pointed out in that comment that you should always SELECT only the fields you need returned to you.
Of course, another evil SELECT is SELECT INTO, creating a temp table without explicitly doing so in your query.
Saying Android is a family of phones is akin to saying Linux is a family of PCs.
Here's a table that summarizes the standards compliance for a few database systems.
I'm not happy that this is required either but there you are.
The Internet is full. Go Away!!!
O'reilly's SQL In A Nutshell is pretty good. It covers standard SQL and the differences between each database(Oracle, MySQL, Postgre SQL, MS SQL).
I've had the (mis)fortune of having to teach courses in Unix using the Visual Quickstart Guides. (I've also checked out several of the other books in the series.) The problem with these books is that they teach by example with very little theoretical background. There's nothing wrong with teaching by example, but if it isn't set in a strong foundation, you end up with students that might have breadth of understanding, but no depth. The books themselves become useless at this point, as the examples are often so narrowly contrived that it's difficult to extrapolate them into more generic scenarios.
There's nothing worse than to see students pay good money for books that will be obsolete or of little use as soon as they finish a class. God knows I bought enough of them when I was in school. For this reason, I avoid the Visual Quickstart Guides and opt for textbooks with more depth of coverage.
No offence but that's heresy where I come from.
It's heresy where I'm working at right now. But that's only because the people who originally wrote the web-app f***ed things up by using ColdFusion for a complex business. CF offers you no good option for separating code, data, and SQL other than stored procs. Java on the other hand...
Would you want to recompile every line of app code before you execute it
SQL is not code. It does not compile down to any form of CPU instructions. It is a data structure designed to look like english. All "compiling" procedures does is pre-parse the query and do some statistical analysis that would otherwise be done at runtime. This is great for really complex queries. However, 90% of the queries in most systems are not seriously affected by "compiling".
On top of that having stored procedures out where a good DBA can get at them in a moments notice so they can search them for dependencies, see their table usage, and analyze indexes without having to sort through a bunch of application code written in a language they may not understand.
Having worked in an environment where we managed excellent performance without resorting to procedures, I can happily say that it comes down to your communication between your teams. If there is a rift between your DB people and your coders, you're going to have problems. Also, it helps a lot to get the database done right the first time. It really isn't too hard, but some DBAs seem insistent on denormalizing this for performance or doing this fun new winding data structure, or other weird crap instead of just *doing* it. Get the database done right and in production and worry about performance characteristics later. 99% of the time, you don't need to do anything about them anyway! (Beyond tweaking a few indexes that is.)
Javascript + Nintendo DSi = DSiCade