Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

SQL in a Nutshell

samzenpus posted more than 5 years ago | from the read-all-about-it dept.

Databases 86

stoolpigeon writes "The cover of SQL in a Nutshell sports a chameleon, the little lizard well known for its ability to blend in just about anywhere. This is a great choice for the Structured Query Language. SQL has been around since the seventies, helping developers interact with the ubiquitous relational database management system. Thirty some years later, SQL grinds away in the background of just about any interactive web site and nameless other technologies. 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. Anyone interacting with an RDBMS is in all likelihood going to need to use SQL at some point. For those who do, who also want a handy desktop reference, SQL in a Nutshell has been there for the last 9 years. The SQL language itself has not stood still over those years, and neither have the products that use SQL, and so now the book is available in a third edition." Read on for the rest of JR's review.It's pretty easy to sum up what SQL in a Nutshell contains. It covers the entire ANSI SQL2003 standard as well as how that standard is implemented in MySQL 5.1, Oracle Database 11g, PostgreSQL 8.2.1 and Microsoft SQL Server 2008. There is a new ANSI standard more recent than the 2003 standard, ANSI SQL2006. This new standard does not change anything covered in the book, but introduced XML and XQuery which are not covered here. The format for conveying all this information mirrors that of the other "...in a Nutshell" books. There are four sections. The first is a very short (15 pages) history of SQL and the second is a summary of foundational concepts. The vast majority of the book is the third section, "SQL Statement Commands." These commands are given in alphabetical order. There is also a table at the very beginning of the chapter listing every command and showing how it is supported by the four platforms.

Each command is presented by starting with a short summary of what it does. This is followed by a table showing which RDBMS products support the command, the proper syntax for the command, key words, command rules, possible issues that may come up and implementation details and examples for each of the four RDBMS products represented. A couple of the differences between the second and third edition are that two RDBMS products were dropped and there are more examples. The products dropped allowed for there to be more examples while also making the book smaller than earlier editions. Anyone working with Sybase Adaptive Server or DB2 UDB will want to hold onto their second edition copy of this book if they want to have that platform specific content available, because it is not in this third edition.

The book states that the dropped platforms were the least popular of those in earlier editions. For those wondering why their favorite RDBMS is not in the list, that gives the answer. To keep length down the number of specific platforms covered was kept to four. Fortunately the books is still of high value for most readers as most decent RDBMS products will support ANSI SQL standards. On those occasions they do not, the reader would have to look to another resource for help. The length issue is easy to understand when looking at the GRANT statement and seeing that it covers over twenty pages. Most of this space is used to explain the various options available on each platform.

The last section SQL Functions documents all of the standard functions with examples and then contains a list of platform specific extensions, grouped by product. There is not a table showing platform support like there was for SQL statements. This section is much smaller, so it really isn't an issue. The single appendix that follows list standard and platform specific key words.

So who would benefit from SQL in a Nutshell? The most obvious to me is the DBA or developer working across more than one of the four platforms presented, especially if they don't move from one to the other too often. Like an Oracle DBA that needs to go do something in MS SQL Server every so often, or the same type of thing between any of the others. This makes for a quick resource that will sort out forgetting how one or the other does things rather quickly. But even if one isn't moving across multiple platforms, unless the whole standard has been memorized, this is a great help.

The second group I see gaining some real good from this book are those new to working with SQL. I've worked with all four platforms and others not covered in this book and on every single one of them I've hit error messages that were anything but helpful. Being able to go directly to a correct statement of syntax and usage is a real help when the system doesn't want to tell what is really going on. It is important to remember that this is a pure reference book. It is not written with the intent of teaching how to use SQL. That said, it covers the entire standard. Much like a dictionary can be used to increase one's knowledge of a language, reading through this reference can be a good way to learn more about SQL. Many introductory texts aren't going to cover the whole standard or as many platform specific details. The student of SQL would get a real jump by working through this book. It is compact enough that while it wouldn't be a thrilling read, it is completely doable.

Who wont like it? Probably anyone who doesn't like any of the other nutshell books from O'Reilly. This book is pretty much exactly like my Unix in a Nutshell, Linux in a Nutshell and MySQL in a Nutshell books. If the format and approach bothers you, don't look for any radical departure that will make it more palatable here. If you are like me and already know you like the format, then this is pretty much a sure thing. For the vast majority of us that work in the database world, this is the reference. I say this keeping in mind the scope of the book. Is this everything one needs to know about SQL? Obviously not. There is much more to be said about SQL as evidenced by all the words that have been said and are out there in print. But when one wants to know quickly about SQL statements and functions, I can't think of a better resource.

Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×

86 comments

Sorry! There are no comments related to the filter you selected.

SQL is going to be around for a long time (0, Insightful)

Anonymous Coward | more than 5 years ago | (#28171629)

Nostra Fucking Damus.

Limit of my SQL.... (3, Funny)

Anonymous Coward | more than 5 years ago | (#28171643)

SQL> select COUNT(*) from 'posts';
1

Re:Limit of my SQL.... (3, Funny)

Jarlsberg (643324) | more than 5 years ago | (#28171941)

I wouldn't want to be the one going through your slow-queries.log ;P

Re:Limit of my SQL.... (0)

Anonymous Coward | more than 5 years ago | (#28174749)

Syntax error!
'posts' is a string which cannot be used in place of a relation, you probably meant "posts".

Re:Limit of my SQL.... (1)

ta bu shi da yu (687699) | more than 5 years ago | (#28174887)

Your SQL skillz are indeed quite limited. That's not correct syntax.

Re:Limit of my SQL.... (0)

Anonymous Coward | more than 5 years ago | (#28187919)

/. is vulnerable to sql injection. tell a friend.

The utility of Nutshell books? (4, Insightful)

CRCulver (715279) | more than 5 years ago | (#28171655)

While I got quite some milage out of my copy of Python in a Nutshell [amazon.com] back in the day, online documentation has much improved and I feel just as comfortable hitting a few keys to get the reference material I want as flipping through pages. O'Reilly Nutshell guides seem to me consigned to that most infamous category of tech reading printed material: the bathroom book.

Re:The utility of Nutshell books? (1)

Smidge207 (1278042) | more than 5 years ago | (#28171921)

"Dear Chris Culver,

I'm sorry for being such a gigantic, insecure shitlord and sending you gimmicky SQL shit scripts twice a year for no damn reason. As a token of the sincerity of my apology, here are pictures of me killing myself by ingesting lines of SQL. It was extremely painful. I hope you will remember me in death as the attention-whoring sycophant I am, and tell your children about the dangers of posting on teh Dot.

May God bless you and keep you in His heart and in yours!"

=Smidge=

Re:The utility of Nutshell books? (0)

Anonymous Coward | more than 5 years ago | (#28173891)

Jesus, you're still a trolling, plagiarizing [slashdot.org] cunt. Please fuck off and die.

Re:The utility of Nutshell books? (2, Informative)

greg1104 (461138) | more than 5 years ago | (#28177903)

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 implement things. A good example here is the messy state of building paginated queries with LIMIT/OFFSET/ROWNUM.

As there is far less variation between, say, Python on various platforms than SQL, this title is somewhat special in that way; I agree that some of the other nutshell books are less relevant nowadays than they used to be. Even when they are the best choice, the printed version isn't necessarily what you want either. Most of my nutshell reading has been through their Safari service lately, rather than the printed books.

I'm looking forward to ... (3, Funny)

Anonymous Coward | more than 5 years ago | (#28171669)

the SQL to this book.

Re:I'm looking forward to ... (1)

CheeseTroll (696413) | more than 5 years ago | (#28177561)

Maybe they'll call it "SQRL in a Nutshell"?

That's not SQL in a nutshell... (5, Funny)

Anonymous Coward | more than 5 years ago | (#28171675)

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.)

Re:That's not SQL in a nutshell... (1)

geeper (883542) | more than 5 years ago | (#28171815)

No, you mean one billion, million, gajillion, fafillion... shababalu... million apologies.

Re:That's not SQL in a nutshell... (0)

Anonymous Coward | more than 5 years ago | (#28177925)

You know, I only clicked on this ato see how long till someone made that joke.

If only... (3, Informative)

Monkeedude1212 (1560403) | more than 5 years ago | (#28171765)

Oracle Documention wasn't as dry as a desert. I like O'Reilly because he's not afraid to converse like a regular human being in his books. I feel like I'm being taught something rather then being shown how to do it. Would I go out and by this book? If I used SQL - definately.

Re:If only... (1)

ianezz (31449) | more than 5 years ago | (#28174493)

If only Oracle documentation wasn't dry as desert

Probably it's part of their strategy to sell you courses, in case you didn't notice.

Re:If only... (0)

Anonymous Coward | more than 5 years ago | (#28181893)

I like O'Reilly because he's not afraid to converse like a regular human being in his books.

And I like Ronald McDonald because he makes my hamburgers just how I like them. [/snark]

For more indepth reading... (5, Interesting)

tcopeland (32225) | more than 5 years ago | (#28171767)

...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".

SQL in a Nutsell (-1, Troll)

LordKaT (619540) | more than 5 years ago | (#28171771)

Have you had any practice with natural language database queries? No? You're a C programmer by trade? Well, then, fuck you.

Nutshell books (5, Interesting)

gambit3 (463693) | more than 5 years ago | (#28171879)

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 (4, Insightful)

gubers33 (1302099) | more than 5 years ago | (#28172077)

You hit that one on the head. I purchased PHP in a nutshell a few months ago, if I didn't have previous experience in PHP from an HTML and a database class I took in college, I would not have been able to understand the book very well at all.

O'Reilly is the Microsoft of book publishers. (-1, Troll)

Anonymous Coward | more than 5 years ago | (#28173105)

O'Reilly is the Microsoft of book publishers: Do just well enough to make money, and don't care about quality at all beyond that.

Re:O'Reilly is the Microsoft of book publishers. (1)

mabhatter654 (561290) | more than 5 years ago | (#28173911)

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.

And we need another SQL book... why? (1)

Uniquitous (1037394) | more than 5 years ago | (#28172043)

As has been noted, it's been around for quite some time now. There was enough uncovered material remaining to justify another book?

Books Are Just Office Trophies (2, Interesting)

WebmasterNeal (1163683) | more than 5 years ago | (#28172231)

I've always thought the books I see in people's offices are just trophies they're showing off stating "I know this language" or "I know that topic". I've actually never seen a co-worker use one of the books either. I agree with some of the other posters, that it's just easier to search Google for something.

Re:Books Are Just Office Trophies (3, Insightful)

Bigbutt (65939) | more than 5 years ago | (#28172823)

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]

Re:Books Are Just Office Trophies (2, Interesting)

computational super (740265) | more than 5 years ago | (#28174577)

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 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...)

Re:Books Are Just Office Trophies (1)

kv9 (697238) | more than 5 years ago | (#28175329)

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:Books Are Just Office Trophies (0)

Anonymous Coward | more than 5 years ago | (#28177853)

Not all programming languages have built in ways to copy an array. If you just learned java you may not realize such a thing exists, the point of the post wasn't that you can't find the answer in google, It's that sometimes you know a solution and implement it without realizing that the language may already have a way to do it on its own. I've had this happen to me many times (ex. php has a function called nl2br that converts new lines in a text files to the br tags in html, it's such a simple task no one bothers to look it up, rather they just do it another way)

Re:Books Are Just Office Trophies (1)

Hognoxious (631665) | more than 5 years ago | (#28175627)

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:Books Are Just Office Trophies (2, Interesting)

Rary (566291) | more than 5 years ago | (#28173709)

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:

  1. I read them on the bus to and from work.
  2. Occasionally I can find something quicker in a book that I'm familiar with which is focused on a single topic, whereas Google is generic and often full of useless crap.
  3. I get my books paid for by the company I work for, and they make nice trophies. ;)

Re:Books Are Just Office Trophies (1)

Insaniac99 (1440867) | more than 5 years ago | (#28177789)

I've always thought the books I see in people's offices are just trophies they're showing off stating "I know this language" or "I know that topic". I've actually never seen a co-worker use one of the books either. I agree with some of the other posters, that it's just easier to search Google for something.

I keep books around because sometimes you don't have access to an internet connection and you want to keep working without worrying about being able to look stuff up when you want.

Re:Books Are Just Office Trophies (1)

turing_m (1030530) | more than 5 years ago | (#28180911)

I've actually never seen a co-worker use one of the books either.

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 only computer books I have ever bought (outside of class) have been database books. And they are not sitting prominently on some bookshelf, they are scattered around the house or workplace somewhere.

Of course, once you are familiar with the layout of the book it is indeed quicker to go to where you know the answer is than use google, which is why the book still has use.

I'm gonna have to give a negative review here (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#28172359)

The cover of SQL in a Nutshell sports a chameleon, the little lizard well known for its ability to blend in just about anywhere.

A chameleon? A chameleon can't save you money on car insurance!

Why only one database language? (4, Interesting)

Brandybuck (704397) | more than 5 years ago | (#28172375)

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:Why only one database language? (2, Funny)

Jarlsberg (643324) | more than 5 years ago | (#28172479)

It works really well, it's an open standard, and it has been with us for about as long as we've had Personal Computers. Let's all be glad Microsoft Access didn't dethrone SQL.

Re:Why only one database language? (3, Insightful)

Brandybuck (704397) | more than 5 years ago | (#28172549)

You can say that for several programming languages as well. There's got to be something else to it.

Re:Why only one database language? (1)

Jarlsberg (643324) | more than 5 years ago | (#28172677)

Point taken. Perhaps SQL, being backend, is less interesting to replace than the programming layer itself? That said, I've seen and tried many different database solutions, going back to Commodore 128 and Geofile, to stuff like Filemaker on Windows, but nothing quite beats SQL.

Re:Why only one database language? (4, Insightful)

Abcd1234 (188840) | more than 5 years ago | (#28172721)

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.

Re:Why only one database language? (3, Insightful)

Estanislao Martnez (203477) | more than 5 years ago | (#28172917)

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? (3, Interesting)

DragonWriter (970822) | more than 5 years ago | (#28174149)

Creating a new query language is *hard*.

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.

Re:Why only one database language? (1)

Abcd1234 (188840) | more than 5 years ago | (#28175095)

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, given that, it's very likely that the language would require new, novel technologies for optimization and implementation... and those things ain't easy to get right.

That said, your point about marketshare is a good one. SQL is well-integrated into many, many languages. Introducing yet another language faces huge barriers to entry, both technological and sociological.

Re:Why only one database language? (2, Insightful)

Estanislao Martnez (203477) | more than 5 years ago | (#28175393)

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, given that, it's very likely that the language would require new, novel technologies for optimization and implementation... and those things ain't easy to get right.

I think DragonWriter is going from the core assumption (which I share) that we're talking about a relational language alternative to SQL, where the differences would be along the following lines:

  1. Closer adherence to the relational model (no NULLs or three-valued logic, no row duplication allowed, etc.).
  2. Friendlier query language with more capabilities for factoring complex repetitive queries.

Note that existing SQL systems also have had many kinds of features added over the years that often require new optimization and implementation techniques (e.g., recursive query extensions, materialized views with automatic query rewrite, MERGE statement). In this sense, really, a relational system with a novel language doesn't have it intrinsically harder than existing SQL databases.

Re:Why only one database language? (1)

Tablizer (95088) | more than 5 years ago | (#28178105)

Closer adherence to the relational model (no NULLs or three-valued logic, no row duplication allowed, etc.).

In practice, row duplication and well-placed nulls can simplify a lot of things. I believe the purists go overboard sometimes.
       

Re:Why only one database language? (1)

The_Noid (28819) | more than 5 years ago | (#28179023)

I can imagine the null bit, but duplicates? Duplicates make a mess of things and complicate the language more than they solve.

Re:Why only one database language? (1)

Tablizer (95088) | more than 5 years ago | (#28182599)

An example would be sending large volumes of data to another company. Suppose the data set has a compound key(s), but the customer doesn't want the keys to keep it slim. We want to do a SELECT that does not include the key(s). This may result in duplicate rows.

Re:Why only one database language? (1)

The_Noid (28819) | more than 5 years ago | (#28299065)

In that case those duplicate rows are useless anyway and should be removed directly. That will also save on the amount of data that needs to be transferred.

Re:Why only one database language? (1)

Estanislao Martnez (203477) | more than 5 years ago | (#28188727)

It depends on what one means by "eliminating nulls"; there's a reason I mentioned NULL and 3-valued logic in the same breath. I certainly would welcome a 2-valued system where NULL was an optionally allowed value for every column (treated as a true value, and not the funny "no value" semantics).

Or even better, we could just have a simplified version of something like Haskell's labeled union types. This would take care of NULL and enumerated types in one feature.

Re:Why only one database language? (1)

DragonWriter (970822) | more than 5 years ago | (#28186179)

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?

The same reason people bother with new Turing-complete programming languages, which can't do anything that isn't possible in existing Turing-complete programming languages: expressiveness, clarity, etc. Usually, new languages don't enable anything that old languages can't do.

Re:Why only one database language? (2, Insightful)

lakeland (218447) | more than 5 years ago | (#28176291)

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 too. Secondly as you say, compiler building is not rocket science and optimisation is part of that. It's a bit different to programming optimisation because you're much more concerned with fetches than instructions but fundamentally the concept is the same.

Of course, that's writing your own language, not writing a decent RDBMS.

Re:Why only one database language? (1)

Rary (566291) | more than 5 years ago | (#28173591)

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:Why only one database language? (0)

Anonymous Coward | more than 5 years ago | (#28174191)

If anything, Microsoft Access helps to enthrone SQL.

Some of us make big buck$ digging the n00bs out from their visually-designed yet still very-much-SQL queries in Access. Once their queries are sophisticated enough to no longer be editable in the visual designer, hello job security!

Re:Why only one database language? (1)

oatworm (969674) | more than 5 years ago | (#28174863)

So YOU'RE the one to blame for using UNION queries in Access! I should've known!

Re:Why only one database language? (0)

Anonymous Coward | more than 5 years ago | (#28172501)

Because SQL is Good Enough(TM)

Re:Why only one database language? (3, Informative)

rubycodez (864176) | more than 5 years ago | (#28172529)

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'

Re:Why only one database language? (2, Insightful)

AkiraRoberts (1097025) | more than 5 years ago | (#28172757)

Having spent a painful few months with Unidata Query Language, I have to say I much prefer SQL. That experience was somewhat less than fun. As for SQL, it's been quite a while since I picked it up, but I recall that it took me all of an hour to get comfortable enough to do damage. And now, some 10 years later, I haven't even come close to exhausting its possibilities. Perhaps that's the reason for its popularity - a nice balance of ease and extensibility.

When it comes to books though, I have a fondness fo Joe Celko's SQL For Smarties. Not the best intro, but something I do keep coming back to. (And yes, while I'm one of those guys with a big pile of books in my office, I do actively use at least half of them).

Re:Why only one database language? (0)

Anonymous Coward | more than 5 years ago | (#28173473)

SQL is the de facto verification suite for an RDBMS engine. Of the various engines I've used in the last 20 years, most had their own proprietary query languages. But if you have to support SQL for procurement compliance (ie the Feds) why bother with two languages? Altho it really comes down to a parser and precompiler feeding a BLR generator. How the BLR gets handled is the fun part.

And it has matured tremendously since the standard was V1.

Re:Why only one database language? (2, Informative)

abigor (540274) | more than 5 years ago | (#28172867)

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? (5, Informative)

hey hey hey (659173) | more than 5 years ago | (#28174913)

It's mainly because SQL was the first (only? someone correct me) language to implement Codd's relational model, via the tuple calculus.

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).

Re:Why only one database language? (1)

abigor (540274) | more than 5 years ago | (#28175281)

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:Why only one database language? (2, Interesting)

TCM (130219) | more than 5 years ago | (#28174185)

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:Why only one database language? (1)

badkarmadayaccount (1346167) | more than 5 years ago | (#28214553)

<ALGOL derivative junkie>What's up with the comparison operator? </ALGOL derivative junkie>

Re:Why only one database language? (1)

nurb432 (527695) | more than 5 years ago | (#28174315)

Because it works, well.

Re:Why only one database language? (0)

Anonymous Coward | more than 5 years ago | (#28174967)

You forgot Erlang.

Re:Why only one database language? (1)

Tablizer (95088) | more than 5 years ago | (#28175367)

There are a gazillion programming languages...Why are there no [common] alternatives to SQL?

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 variations on Chris Date's "Tutorial-D" with some actual implementations floating around, but haven't taken off. While better than SQL, it's driven more by idealism/purism than practical thinking in my opinion. Plus, it mixes in-fix and pre-fix syntax unnecessarily and is a bit keyword-happy, risking falling into the same trap as SQL did.
   

Re:Why only one database language? (2, Informative)

Hognoxious (631665) | more than 5 years ago | (#28175649)

But only one SQL.

I know for a fact that isn't true. I work with SAP, which uses a slightly odd dialect/subset of it.

Re:Why only one database language? (0)

Anonymous Coward | more than 5 years ago | (#28179457)

LINQ?

COBOL (1)

SanityInAnarchy (655584) | more than 5 years ago | (#28172977)

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 -- for instance, there are things I can imagine doing in Erlang that I'd never attempt in C. But people do anyway, and even modern high level languages seem to start as interpreters written in C.

Personally, I'd rather see CouchDB [apache.org] mature, and see SQL become more like COBOL, but that doesn't seem likely to happen soon.

SQL injection (0)

Anonymous Coward | more than 5 years ago | (#28173267)

Does the book cover SQL injection - how to and prevention/detection?

Re:SQL injection (2, Insightful)

Anonymous Coward | more than 5 years ago | (#28173411)

Sanitizing your input on the application layer or db abstraction layer is probably the way to go towards injection prevention (and also using as-restrictive-as-possible DB permissions.) Those layers are almost surely not written in pure SQL, thus I feel as if injection prevention is somewhat off-topic for this book, which is about the language itself.

Re:SQL injection (3, Insightful)

FranTaylor (164577) | more than 5 years ago | (#28174659)

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.

SQL is just a TLA (1, Interesting)

Anonymous Coward | more than 5 years ago | (#28173321)

Actually according to both the ANSI and ISO stds, SQL has no translation from the acronym. Now before flames start, please read the standards. A friend of mine has been an active member of the ANSI committee since the early '90's, and I have presented proposals to the committee.

Really, here is SQL in a nutshell... (1)

leamanc (961376) | more than 5 years ago | (#28174299)

SELECT * FROM table WHERE field LIKE condition;

INSERT INTO table (field1, field2, field3) VALUES(value1, value2, value3);

That's SQL in a nutshell. I think anything more than that is a fairly detailed book.

Re:Really, here is SQL in a nutshell... (0)

Anonymous Coward | more than 5 years ago | (#28175135)

SQL! Right in the nuts--HELL!

Re:Really, here is SQL in a nutshell... (1)

Samah (729132) | more than 5 years ago | (#28189715)

You're not going to accomplish much with a select and insert. As long as you know all the CRUD syntaxes (Create, Read, Update, Delete) you can use an existing database, and although I'd hardly call it "in a nutshell", it's the first thing anyone dabbling with SQL should know before they start reading a few chapters into "a detailed book" and get to creating and modifying schemas.

SQL is not a standard (3, Interesting)

FranTaylor (164577) | more than 5 years ago | (#28174575)

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.

Re:SQL is not a standard (1)

Tablizer (95088) | more than 5 years ago | (#28182779)

Why can't people just implement standard ANSI SQL and be done with it?

Partly because the standard is too complex, and partly because non-standard extensions reduce the chance of people switching vendors. DBMS vendors don't want people to migrate to other DBs. Thus, they implement proprietary features and sometimes nifty shortcuts that get you hooked because converting would be too difficult and/or you'd lose the nifty shortcuts.

No DB2? (2, Interesting)

metamatic (202216) | more than 5 years ago | (#28174939)

The book states that the dropped platforms were the least popular of those in earlier editions.

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:No DB2? (1)

greg1104 (461138) | more than 5 years ago | (#28177983)

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:No DB2? (1)

Tablizer (95088) | more than 5 years ago | (#28178135)

Note that the IBM database sales may include IMS, not just DB2.

Re:No DB2? (0)

Anonymous Coward | more than 5 years ago | (#28181077)

True or not, I'd been told that IBM's market share was skewed by the fact that it's included by default in all their mid-range (non-UNIX) and mainframe systems and that IBM counts each user of those systems as a user of DB2 whether it's used by their app or not.

Fp Hompo (-1, Troll)

Anonymous Coward | more than 5 years ago | (#28175833)

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>