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
I liked their javascript and XML quickstart guides; they're basically ways of getting up to speed on something really quickly, and for relatively simple subjects (like Javascript, html, and xml) they might be all you need outside of web searches. The xml book had some really nice info about stylesheets and XSLT, for instance, and I use the stylesheet reference even when I'm just doing some HTML.
The books are cheap (twenty or thirty bucks) and small (easy to carry in a backpack). I think they're a really good value. Although, I wouldn't buy one for a more in-depth programming language, for the simpler stuff (html, xml) they're great.
Farewell! It's been a fine buncha years!
If an SQL book isn't easy to search I'm not buying it.
Omnis amans amens
... 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
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.
I would agree with the text that you cited, right up until he talks about the opposite.
The two are equally important, and both are critical to a good technical book. You cannot have a good tecnical book that is poorly written. You simply cannot.
I remember the original X reference set from O'Reilly, and the whole reason that they were a success was that they were essentially duplicates of the online X documentation, which was some of the best written toolkit documentation, ever.
Had those been just as technically accurate, but even just a little harder to navigate and use, they would have been nearly useless, given the complexity of the topic.
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.
I have the XML and the Web-Based UI ones. They're both very handy to have around, and easier to carry than toting O'Reilly books everywhere. They also cover more ground than the O'Reilly "Pocket Reference" series tend to.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
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.
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!!!
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.
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).
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.
2 things:
you can easily define all columns in all tables as NOT NULL. so if YOU don't want to use them, or consider tham a "poison pill" then don't allow them. But some of the rest of us might find a value in a NULLable column. For instance some rows, but not all in table A might have a relationsip to table B. Leaving a NULL value in that column (Foreign Key) pretty clearly expresses this concept.
Are you certain SQL was modeled on COBOL?? Granted I never used COBOL on the job, but what I recall of the language doesn't much remind me of SQL.
MySQL is so full of little incompatibilities with SQL92 it's not even funny. Here's one (of about a hundred examples you can come up with if you scour the SQL92 spec and compare what it says to what MySQL does.)
SQL92 says that if you multiply two numerics with a precision of say x and y digits to the right of the decimal place respectively, the result should have x+y digits of accuracy to the right of the decimal point.
i.e.
create table test (num1 numeric (10,2), num2 numeric(10,3));
insert into test values (4.54,8.679);
select num1*num2 from test;
you get 39.403 for an answer. You're supposed to get 39.40266 for an answer, but MySQL just chops off the extra digits, in clear violation of the SQL92 standard.
Because of this, it's unlikely MySQL will be used by anyone (with a brain and capable of testing MySQL for compliance anyway) in a financial application like Oracle or Postgresql would be suited for.
There are plenty of other issues with MySQL. Anyone who's used databases a lot before seeing MySQL just shakes their head and laughs at the idea that someone would use it to store critical data.
--- It is not the things we do which we regret the most, but the things which we don't do.
SQL:1999 has been defined for years and some of the DBMSs have actually implemented some of its features. Yes, SQL:1999 is big and perhaps bloated in comparison with SQL-92, but it's not that bad if you concentrate on the core parts. Some of the news in SQL:1999 are actually clarifications on stuff in SQL-92.
SQL:2003 will probably be agreed on this year.
- So I find it strange to use the more than a decade old SQL-92 as the platform for a book published in the year 2002.
Another thing: I'd say it's "ISO SQL" nowadays (or ISO/IEC SQL), not "ANSI SQL".
Apart from that, I've put the book on my Safari bookshelf and look forward to reading (at least parts of) it. Unfortunately, it seems that Safari's index of the book is currently lost.
I like the approach where you start by thinking about the standard way to do it, and then try to squeeze your design into a real-World product. It's too bad that the official standard isn't online; fortunately, it's possible to get something close to being official. When trying to set up an initial, standards compliant schema, it's nice to have an evaluation-installation of Mimer SQL to play with. I wish it were open source or at least had an official price tag.
I expect that the book could be relevant in connection with a page about SQL differences that I've started writing, after having had to port some SQL from PostgreSQL to MSSQL.
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.
Who cares, this isn't a $200 Calc text, it's ~$15 at most of the major online retailers. It's kind of like cliff's notes or dummies books, enough to get you started but not something you learn everything you need from.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Yes, it's more important to understand the language than to have good, solid code examples which I can't actually use because either they don't do what I need to do or I just can't understand them well enough to implement them where I need them. It's also more important to be able to write the best code for the job than to be able to grab some inefficient code which allows me to work around its inadequacies for my specific usage so that I can just about do what needs to be done. I choose comprehension over examples.