| SQL in a Nutshell, 3rd Edition | |
| author | Kevin Kline, Daniel Kline, Brand Hunt |
| pages | 590 |
| publisher | O'Reilly Media Inc. |
| rating | 10/10 |
| reviewer | JR Peck |
| ISBN | 978-0-596-51884-4 |
| summary | Covers the entire ANSI SQL2003 standard as well as how that standard is implemented |
All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.
Limit of my SQL.... (Score:3, Funny)
SQL> select COUNT(*) from 'posts';
1
Re:Limit of my SQL.... (Score:4, Funny)
Parent
Re: (Score:2)
Your SQL skillz are indeed quite limited. That's not correct syntax.
The utility of Nutshell books? (Score:5, Insightful)
Re: (Score:3, Informative)
Typically the on-line reference manuals you'll find show how SQL works on one particular platform. The main value of the "SQL In a Nutshell" books has always been the way you can easily compare what's available on multiple database platforms. You will need to be aware of that sort of thing if you want to support more than one database in your code. And even if you're using some middleware to abstract that away, knowing which features work well and badly on various platforms can guide how you should imple
I'm looking forward to ... (Score:3, Funny)
the SQL to this book.
Re: (Score:2)
Maybe they'll call it "SQRL in a Nutshell"?
That's not SQL in a nutshell... (Score:5, Funny)
That's not SQL in a nutshell... This is SQL in a nutshell:
SQL: HELP! I'M TRAPPED IN A NUTSHELL
SQL: WHAT KIND OF SHELL HAS A NUT LIKE THIS?!?
(my 100 billion apologies, Mr. powers.)
If only... (Score:3, Informative)
Re: (Score:2)
Probably it's part of their strategy to sell you courses, in case you didn't notice.
For more indepth reading... (Score:5, Interesting)
...try Stephane Faroult's The Art of SQL [amazon.com]. I've read both that and his "Refactoring SQL Applications"; I think I got a little more out of the former.
But anyhow, in both books he has a distinct and lively writing style and includes lots of anecdotes. His style kind of reminds me of Betrand Meyer... for those who have read Meyer's 1000 page tome "Object Oriented Software Construction".
Nutshell books (Score:5, Interesting)
while the "Nutshell" books make great gifts for someone somewhat experienced in a topic, it needs to be pointed out that they're not necessarily the best option for a beginner.
Re:Nutshell books (Score:4, Insightful)
Parent
Re: (Score:2)
I find across the board the O'Reilly books are usually pretty good. There are some that are "regurgitated" manpages. Many are "gold standards" in their topic... I'd say they have more "gold standards" than any other publisher. I've seen individual books from other publishers that have very good individual authors but not consistently good across the whole lineup. I guess I feel more comfortable "buying blind" on a topic I don't know with the O'Reilly brand than any other.
Books Are Just Office Trophies (Score:2, Interesting)
Re:Books Are Just Office Trophies (Score:4, Insightful)
One of the problems with google is that if it's sufficiently generic, you'll get 3,600,000 pages. I can just grab the appropriate book and have a better chance of finding my answer. Another issue is the number of spammers trying to catch your attention by snatching search results just to be able to point you to their site.
O'Reilly and Addison-Wesley have good reputations for putting out quality books. Searching and wading through blogs and difficult to navigate web sites (I'm looking at you Sun) to find the right answer can be lengthy and a crap shoot too. Picking up the subject matter book gives a good chance of having the right answer immediately.
So yea, I have a bunch of books here and at home. I also subscribe to O'Reilly's Safari Bookshelf. I haven't read each and every one, but they've all been helpful at one point or another in my career.
[John]
Parent
Re: (Score:3, Interesting)
Not only that, but books are good for things that you wouldn't think to Google. I noticed recently that a coworker did this (slightly simplified to illustrate the point):
public void doSomethingOrOther( int[] a )
...
{
int b[] = new int[ a.length ];
for ( int i = 0; i < a.length; i++ )
{
b[i] = a[i];
}
}
I pointed him to "System.arraycopy" which is quite a bit faster and does the same thing on a single line of code. This just isn't something you'd find out about unless (a) you read a book o
Re: (Score:2)
I pointed him to "System.arraycopy" which is quite a bit faster and does the same thing on a single line of code. This just isn't something you'd find out about unless (a) you read a book or (b) had a coworker who read a book. (Well, I guess if you read all the online javadoc line-by-line, you'd discover this, too...)
here's a hint for your fellow janitor: before doing something stupid, google it [google.com]. what's he gonna do next? copy a string byte by byte? shit, even Java programmers should know these basic things.
Re: (Score:2)
I second what you said about google; you get too many hits, which is as bad if not worse than getting none. As an aside, I've also noticed that recently the hits it returns often don't contain what I searched for.
I still have Unix in a nutshell, it saved my life when I made the move from a mainframe environment.
Re: (Score:3, Interesting)
I have a large library of technical books, but I also use Google as my primary reference source. The reasons I continue to buy books are:
Re: (Score:2)
I find a book can be helpful when I'm getting a general overview of a complex topic. You can lay in bed (or on the floor) and read, which is harder to do with google. I found it difficult to grok how to design database tables for example, without sitting down, reading and thinking. And falling asleep, and getting up and doing it all over. It's a lot harder to learn databases than say, learn enough Perl to do something useful. Hence why the on
Why only one database language? (Score:5, Interesting)
There are a gazillion programming languages, with new ones added every day. C, C++, Java, C#, Objective C, Pascal, Modula 3, Ada, Ocaml, Haskell, Lisp, Scheme, Python, Ruby, Perl, Lua, Javascript, etc. There's even a choice of shell scripts: sh, csh, bash, ksh, zsh, etc.
But only one SQL. I'm sure there are some other database query languages, but they are so obscure that no one but the longbeards have ever heard of them. Why is that? Why are there no alternatives to SQL? Not just minor variants, but actual alternatives.
Re: (Score:3, Funny)
Re:Why only one database language? (Score:4, Insightful)
You can say that for several programming languages as well. There's got to be something else to it.
Parent
Re: (Score:2)
Re:Why only one database language? (Score:5, Insightful)
Creating a new query language is *hard*.
I mean, I can sit down and create a new programming language fairly easily. Hell, most computing science students write a compiler at some point during education. But a new query language? That requires a DB engine, a query optimizer, and who knows what else. All to replace a language that, thus far, has worked exceedingly well.
That said, as another poster points out, there are other languages out there, XPath being the most notable (CSS selectors also come to mind). But none of them are as clear, simple, and straightforward as good ol' SQL, which, I think, says something about its design.
Parent
Re: (Score:3, Insightful)
I think you very much overstate the "clarity," "simplicity" and "straighforwardness" of SQL; there are many well-studied ways in which a relational language could be better than SQL. But I do think you've hit the nail on the head otherwise: designing and implementing a credible RDBMS is extremely hard compared to designing and implementing a programming language, and no relational query language is going to go anywhere without being paired to a good RDBMS.
Re:Why only one database language? (Score:4, Interesting)
No more so than creating any other new programming language; most functional programming languages (and plenty of not-particularly-functional programming languages that have functionally-inspired features) have querying constructs roughly comparable to those in SQL or other dedicated query languages (and often clearer, more straightforward, and more expressive than SQL.)
What's hard to build is efficient storage engines and query optimizers, not query languages, but once those are built, the language you express the queries in shouldn't matter much as long as the what is expressible is the same.
The really hard part though is finding a market for a new dedicated query language; a big selling point of a dedicated query language is because it will be generally familiar for most users regardless of what prior products from a large set the user has used, and anything that isn't SQL, whatever it might have going for it, is going to lack that advantage as a query language.
Parent
Re: (Score:2)
What's hard to build is efficient storage engines and query optimizers, not query languages, but once those are built, the language you express the queries in shouldn't matter much as long as the what is expressible is the same.
I disagree. Existing query optimization and execution engines are built with the capabilities and constructs of SQL in mind. A new query language, on the other hand, presumably exists to enable things which existing languages (like SQL) don't... otherwise, why would you bother? So
Re: (Score:2, Insightful)
I think DragonWriter is going from the core assumption (which I
Re: (Score:2)
I can imagine the null bit, but duplicates? Duplicates make a mess of things and complicate the language more than they solve.
Re: (Score:3, Insightful)
Nah, it's easier than that.
Firstly, writing a DB engine is pretty easy. B-Tree implementation is a standard 2nd year assignment, hash is first year, and trying them into a database with persistent storage would probably still be 2nd year or 3rd year at worst. Transations (undo segments and the like) are harder, but you could leave them out.
Query optimisation firstly isn't in SQL, though I'd be lying if I said it was in relational algebra. Certainly it is in an intermediate language that is convertible to
Re: (Score:2)
Programming languages do many, many, many different things in many, many, many different environments. Database query languages do, more or less, one thing in one environment. If you've built a good database query language, there's no need to build another one. However, if you've built a good programming language, somebody else will find a situation in which it's not so good, and will therefore want/need a different one.
Re: (Score:2)
Re:Why only one database language? (Score:4, Informative)
both XQuery and XPath 2.0 are used in the "real world". Unidata Query Language is used in many enterprises, I worked at a manufacturing plant where the MRP system used Unidata as back end.
so quit yer bellyachin'
Parent
Re: (Score:2, Insightful)
When it comes to books though, I have a fondness fo
Re: (Score:3, Informative)
It's mainly because SQL was the first (only? someone correct me) language to implement Codd's relational model, via the tuple calculus. The relational model is of course the basis for relational databases, so the idea was SQL would be provably correct in its representation of the relational model. There is a document called The Third Manifesto that details why this is not the case, and makes some suggestions for the way forward, but I don't remember much else about it.
Re:Why only one database language? (Score:5, Informative)
Hardly. Quel [wikipedia.org] predates SQL, and was superior in almost every way. However, SQL had IBM behind it, and Quel just had UC Berkeley (guess who won that battle).
Parent
Re: (Score:2)
Yes, I knew someone would correct me, thanks ;)
Anyway, my point was that any new language would have to have a similar relationship to the relational model that SQL and I assume Quel do.
Re: (Score:3, Interesting)
There's even a choice of shell scripts: sh, csh, bash, ksh, zsh, etc.
Objection!
You use different shells for different interactive properties. Scripts should be written for #!/bin/sh. And yes, that's /bin/sh to you, no /bin/sh == /bin/bash perversion.
Re: (Score:2)
Because it works, well.
Re: (Score:2)
Indeed! Over at the c2.com wiki we've been wondering that also. We've listed several limitations or annoyances of SQL that are not inherent to relational theory itself.
I've even created my own draft relational query language called SMEQL ("smeegol") roughly based on an old IBM experimental language called "Business System 12" that has a functional programming feel and is more re-composable than SQL.
Another option is
Re: (Score:3, Informative)
I know for a fact that isn't true. I work with SAP, which uses a slightly odd dialect/subset of it.
COBOL (Score:2)
New alternatives are popping up constantly but I'm going to go out on a limb and say that SQL is going to be around for a long time.
That's pretty much guaranteed. COBOL is still around.
There absolutely are better alternatives, for almost every situation. No one in their right mind starts a new system in COBOL [coboloncogs.org], when they have a choice.
Yet COBOL is still around, and will be still around for awhile. So will SQL.
The only question is whether SQL will be like COBOL or like C. I could make a similar case for C being obsolete, and there are certainly many cases where a performance penalty is well worth it to get some other desired feature -- fo
Really, here is SQL in a nutshell... (Score:2)
That's SQL in a nutshell. I think anything more than that is a fairly detailed book.
SQL is not a standard (Score:4, Interesting)
If it were, there would not need to be vendor-specific examples in every SQL book.
Why can't people just implement standard ANSI SQL and be done with it?
I am really tired of vendors (MySQL) and their non-standard SQL. I want my JDBC applications to just work and not have special-case code for each database.
No DB2? (Score:3, Interesting)
Last I checked, IBM DB2 had the biggest market share of any SQL database. (Link to 2003 Gartner Study [programminglearn.com], and I don't think the situation has changed much.)
So do DB2 users just not buy books like SQL In A Nutshell? Or have O'Reilly made a serious mistake here?
From my point of view it looks like a mistake, as I'm only interested in PostgreSQL and DB2... but then again, I work for IBM, so maybe I'm a special case?
[Opinions mine, not IBM's.]
Re: (Score:2)
The last Gartner Study [reuters.com] I read analyzing 2007 put DB2 as basically tied for 2nd place with Microsoft at around 20% each, and both combined are behind Oracle. But market share is not the same as user base, and there I'd bet DB2 is far behind MySQL at least. You might have a case for putting DB2 ahead of PostgreSQL as far as user base goes, but O'Reilly does have heavy open-source roots in their publishing line that I suspect swayed their focus against IBM's product here.
Re: (Score:2, Insightful)
Re:SQL injection (Score:4, Insightful)
It doesn't tell you how to touch-type or tie your shoes either.
Use parameterized queries and you don't ever have to worry about SQL injection again.
If your development environment doesn't support them, it's a BUG, and you NEED to report it.
Parent