SQL Vs. NoSQL: Which Is Better?

Nerval's Lobster writes "For the past 40-some years, relational databases have ruled the data world. Relational models first appeared in the early 1970s thanks to the research of computer science pioneers such as E.F. Codd. Early versions of SQL-like languages were also developed in the early 70s, with modern SQL appearing in the late 1970s, and becoming popular by the mid-1980s. For the past couple of years, the Internets have been filled with heated arguments regarding SQL vs NoSQL. But is the fight even legitimate? NoSQL databases have grown up a bit (and some, such as Google's BigTable, are now mature) and prove themselves worthy. And yet the fight continues. Tech writer (and programmer) Jeff Cogswell examines both sides from a programming perspective."

Comments

Flamebait in Headline

[Fwipp]

SQL and NoSQL are different, with different use cases.

Re:Flamebait in Headline

[medv4380]

Actually the headline is a typical news headline stated as a questions. So the answer is always no.

Re:Flamebait in Headline

[Jeremiah Cornelius]

"Hammer or Shovel! Only one of these will leave the room as the single, ULTIMATE TOOL!"

I believe, in such cases, that the answer is always "The Ohio Players".

Re:Flamebait in Headline

[s.petry]

Exactly! As with all technology each has a purpose. I remember the old days when all we had was binary databases, the reason for the SQL was that the binary blobs could not do everything needed. While I find it interesting that we have seen a lot of growth in the older technology, it is not something new. SQL won't be going away, just like NoSQL never really went away (it just saw negative to no growth for a very long time).

Remove the bias and fan boy status and what do you have? You have 2 technologies to choose from which can get the job done regardless of your use case.

Re:Flamebait in Headline

[gl4ss]

The heated battle is mostly heated because Google keeps throwing oil into fire. Oracle and Microsoft gladly showed that relational big corporate databases are much faster and better than NoSQL. But Google keeps promoting their own shit because it's their own shit. And it's shit.

that statement makes no sense. just answering the headline with "BABABABA" makes more sense.

maybe if the submitter of the article had included an actual scenario..

Re:Flamebait in Headline

[Anonymous Coward]

SQL and NoSQL are different, with different use cases.

No. Wrong. Clearly, $CHOICE is superior in all cases. If you think you've found a situation in which !($CHOICE) is better, you're obviously using $CHOICE wrong and should RTFM before you EVER say anything against it again, n00b.

Re:Flamebait in Headline

[Eponymous Hero]

agreed. even the summary is nothing but provocation.

NoSQL databases have grown up a bit (and some, such as Google's BigTable, are now mature) and prove themselves worthy. And yet the fight continues

too bad the ones perpetuating the fight haven't grown up.

Tech writer (and programmer) Jeff Cogswell examines both sides from a programming perspective.

no thanks. how about we just talk rationally about scenarios in which you would prefer to use one or the other? how about speaking intelligently about the benefits of both, and how they should be properly used, instead of giving any attention to the bickering that is only going on by people who don't know how to use either one properly?

check out this gem FTA:

2. Relational data doesn’t map well to typical programming structures that often consist of complex data types or hierarchical data. Data such as XML is especially difficult because of its hierarchical nature. Complex objects that contain objects and lists inside of them do not always map directly to a single row in a single table.

you mean the developer actually has to do his job? the developer actually has to tell his ORM what he's thinking, and organize his objects in a way that makes the data well understood? shudder to think. "i thought it was all drag and drop in visual studio, i never became a programmer to WRITE CODE!!! omg!!"

but wait, here's #3 in their list:

3. Relational data doesn’t map well. Combine that with the need to handle the syntax of SQL, and writing client code for accessing SQL databases becomes difficult.

look, it's just #2 written a different way. why should i care what incompetent programmers and dbas think about nosql? i eat their breakfast for lunch everyday.

Re:Flamebait in Headline

[GuldKalle]

The name noSQL itself is flamebait.
But yes, a much more informative article would br: SQL or NoSQL - when to use what.

Re:Flamebait in Headline

[Anonymous Coward]

Last I checked, Google is not selling "their own shit" as a product.

I am speaking here as a professional SQL developer with nearly a decade of experience and a very solid knowledge of relational theory. For many of the things we use relational DBs for, they are the best solution. But there are a lot of other applications for which a RDBMS is overkill, and a tool like BigTable is ideal. There are others where a single XML file would be better. There are others where a simple text file would be better.

If people would stop arguing that you have to use a jack-hammer to solve a problem best suited to a ballpeen, we wouldn't have these arguments.

Re:Flamebait in Headline

[SQLGuru]

And thus, the answer (as in most cases with technology) is "it depends".

There is no one tool to rule them all. The various languages and technologies were created to solve a specific problem that a different tool or technology didn't quite address well. SQL is great. NoSQL is great. Both have their place. The key is using the right tool for the problem and to quit thinking one is better than the other.

Re:Flamebait in Headline

[VGPowerlord]

SQL and NoSQL are different, with different use cases.

No. Wrong. Clearly, $CHOICE is superior in all cases. If you think you've found a situation in which !($CHOICE) is better, you're obviously using $CHOICE wrong and should RTFM before you EVER say anything against it again, n00b.

Ah, but then you have to look at the implications of $UNRELATED_PROBLEM. After all, $CHOICE can't $BUZZWORD1, at least not without support for $BUZZWORD2.

Once $CHOICE supports those, then maybe it'll be better in all cases.

Re:Flamebait in Headline

[Dragonslicer]

Complex objects that contain objects and lists inside of them do not always map directly to a single row in a single table.

This is so true. If only relational databases had a way to connect a row in one table to a row in another table. It would be even more awesome if it could connect a row in one table to more than one row in another table. Just imagine if you could, I dunno, like, join the data together or something.

Re:Flamebait in Headline

[Sarten-X]

That's because the factors for the "it depends" answer depends on other aspects, like the exact characteristics of your application. Here's some rules of thumb:

NoSQL is good for statistics, where a few missing records won't matter. It's good for absorbing an enormous number of write operations at high speed. It's good for parallel computation across distributed data sets. It's good for when you have a lot of data to store, and little insight into how it will be queried in the future (management loves this one).

RDBMS is good for absolute consistency. It's good for serving an enormous number of parallel reads at high speeds. It's good for legacy applications, and applications that have to interface with legacy applications. It's good for small-scale projects that just need to work now. It's good for compatibility.

Of course there are exceptions to every statement I just made, but the nuances are subtle. Just bear in mind that NoSQL is generally more about single-record storage, where a RDBMS is by nature based around sets. If your algorithms are more easily applied to one model over the other, it might be a good indicator of what kind of storage to look at.

Re:Flamebait in Headline

[PhrstBrn]

Every time I see this debate, this is what I always see. "it depends"

it depends on WHAT?! NoSQL people keep touting features, SQL people keep touting history, neither say "well, RDBMS is best suited for [insert descriptions here], while MongoDB is best suited for [insert descriptions here] and Lucene/Solr is best suited for [insert descriptions here]".

RDBMS is better for dealing with transactions. NoSQL is really bad at dealing with transactions, as they don't guarantee immediate consistency (and if they do, it comes with a huge performance cost, slower than that of an RDBMS). NoSQL is better for general data warehousing. You can do data warehousing with a RDBMS, it's just extremely inflexible at that task.

Re:Flamebait in Headline

[afidel]

It very much depends on the kind of data warehouse. If it's a financial data warehouse I think using NoSQL is insane (we report to the SEC out of our data warehouse, transactional integrity is important!). If your data warehouse is just trying to answer the question "what do users of my social media site find interesting" then sure, go at it with a NoSQL solution. Ultimately with NoSQL you're trading data integrity for performance/scalability, which is fine as long as you understand what the tradeoff is.

Re:Flamebait in Headline

[LordLucless]

In that case, I think the answer to "what is the greatest tool?" would be "the person asking the question".

"No"

[Anonymous Coward]

"No".

Re:"No"

[TeknoHog]

*sigh* Oh, for fuck's sake, some hipster asshole found that someone coined some convenient, soundbite-sized phrase, so now all the we're-definitely-not-sheep! are going to think they're smart and clever by linking to it every other fucking article, aren't they?

No.

Stupid question

[adturner]

Might as well just ask: Which is better a BMW M3 or Ford F350 4x4 with 6.7 diesel?

Both are great, have their place and will get you from point A to B, but neither are a practical replacement for the other.

My current programming project is a mixture of Cassandra and Oracle (although, to be honest, I'd rather be using PostgreSQL or even MySQL).

Re:Stupid question

[lambent]

Ability to tune for performance on know hardware; better permissions structures; ability to get support from the company; data security, replication, backup; clustering; not wanting to reinvent the wheel using man-hours when you can more easily pay for a known working solution that is well documented ...

etc. There are a lot of reasons.

Re:Stupid question

[The Dancing Panda]

Not necessarily. MSSQL and Oracle come out as legitimately faster in many use cases. MSSQL is generally easier to set up and use in a small to midsized application than most other offerings, and the code written to use the database can be easily migrated from SQL Express all the way to MSSQL enterprise. MySQL is great, but has been shown to not perform as well on giant data sets. Oracle usually wins in those cases, but it is a BITCH to configure. MSSQL also supports a lot of different data types natively.

The Open Source solutions are great for a small project, but from many DBAs I've spoken to, don't scale well.

I should note that I use MySQL on all my home projects. It works wonders. But I wouldn't choose it if I was looking to do something that requires blazing fast query speeds. MS and Oracle have some good products here, despite Oracle not being able to design a user interface to save their lives. MS is good because they bought it, but the Management Studio is quite nice to work in (MS is very good at making developer tools).

MySQL vs MongoDB

[djbckr]

I'm sure many of you reading this have seen this, but it's still funny anyway... http://www.youtube.com/watch?v=b2F-DItXtZs

Dumb question

[dissy]

Replace "SQL" with "hammer" and replace "NoSQL" with "Screw Driver" and then ask the question again. You will see how silly it actually is.

The right tool is best for the particular job at hand, always. If you refuse to define the job, it is not possible to guess ahead of time which tool will be better for it.

Re:Dumb question

[steelfood]

You don't even have to leave computer science for an analogy. Is a hash map better than an array?

That's effectively the question. Those who cannot answer this question have no business writing code.

The answer to all "Which is better" questions...

[Jason Levine]

Here's the answer to pretty much every "Which is better" question:

- Option 1 is better in cases where option 1 provides more advantages and less disadvantages than Option 2.

- Option 2 is better in cases where option 2 provides more advantages and less disadvantages than Option 1.

- In cases where neither Option 1 nor Option 2 provide a clear advantage/disadvantage distinction, neither is better and either may be used depending on preference.

Rarely is the answer ever "X is better than Y in all possible cases."

SQL for Some Projects ...

[eldavojohn]

Kang: SQL for all.
*crowd boos*
Kang: Very well, NoSQL for anyone.
*crowd boos*
Kang: Hmm... SQL for some projects, miniature NoSQL implementations for others.
*crowd cheers*

Re:No!

[greg1104]

Betteridge's Law of Headlines is the rule you're looking for.

an Oracle DBAs perspective

[Anonymous Coward]

For generic applications that do not have a vast amount of user volume or data set size, NoSQL or any SQL Generator is fine. It is also fine for most of the standard and generic go down a primary key query or do a simple join. However, the more complex queries on larger systems need reviewing. The biggest problem with NoSQL is developers just don't want to be bothered and expect their procedural logic to automatically run in a 20 terabyte database that gets over a million hits a minute. This is the higher end for systems I work on, but it also happens in smaller ones.

We get by far the worst SQL submitted to us by developers who generate SQL and in general don't know anything. Large Databases rarely stay extremely well normalized. There are rarely data architects around to enforce this. Developers who are in a hurry to meet deadlines denormalize and just add columns. When you do this, over time your sql gets more complex and query generators are not very good.

Query generators can generate alot of basic sql, but as time goes on requirements get more complex. Developers are building on what other developers did before them. A lot of this data is not normalized and have ridiculously complex logic. We generally get emails from developer going 'this query is slow' and that is it. Or we get I did a query just like this before, but this one is slow. The query generator may be making queries on the fly. So they think its the same thing, but its actually different.

One other thing that often happens that people overlook is that these tools generate too much SQL. Instead of getting data in 1 sql statement and have a normalized set of tables, I have clicked a button and run 15 sqls serially. When you get alot of traffic, the round trips and the CPU increase adds up. Developers don't know this is happening because it is all done behind the scenes.

I have had developers with over 10 years experience (some up to 30 years) who can't even figure out the following:

1. why a query that returns millions of records is slow or can understand the question of 'what the hell is the user going to do with all this?'
2. why taking fields out of the 'where' clause can affect the query. Dude, cause your no longer using an index.
3. why running the same query millions of times in a loop would be slow (this is serial). databases are optimized to do stuff in straight sql. Ok this one is not really easy to get at first and it won't be obvious, but if you have done this for 10 years you should have seen it and if I tell you this 5 times and you keep doing it... seriously. This is not that hard.
4. how different parameters can affect a query. If you run a query that brings back one record, then change the parameters and it has to go through 500 gbs of data your response time will slow down a bit right?
5. 'it worked in dev'. your Dev DB had tables with 10 records. Prod has 20 terabytes of data. We have told you that prod is much bigger. So you need to atleast check to see if its using an index. This is NOT difficult and I show them how, but they don't care.
6. your queries are 'slow' because your query generators run 26 queries(serially) when I click this one button. You can combine these to 4 or less and if you pay more attention to the data model and let us making a few simple changes we can get it to 1. However, the 4 i am giving you is fine for now. i can even show them how to audit their sessions activity and how to run a simple query to see what is going on. They click a button and they can see exactly what is happening in the DBA. Most don't care.

My biggest beef is I tell them what is wrong, I try to explain to them why this is a problem and the vast majority just don't care. They ignore and then do the same thing again. Apparently they don't care that I am subject to 24x7 paging on this stuff and I can't go home if users are complaining, while the developers can go home to their families.

My other beef is that SQL is not that hard. Its easier than coding. I have been a developer before

Re:an Oracle DBAs perspective

[vlm]

Let me put in the "answers" you probably get from noob programmers.
1) I don't know what a WHERE clause is so I SELECT * and use if statements on each row of the gigs of results
2) I don't know what a index is
3) I don't know what a JOIN is so they wrote one in software
4) ... I donno some workplaces need employee drug testing?
5) I don't have a real DEV box. Oh I've got a box that endusers can't reach full of non-production code, but I don't have a DEV box that I can test real code on real data. You could simulate a 20 TB prod by provisioning a 2 TB dev on a virtual image of only 1/10th "power", at least for linear scale problems (and the major problems are never linear scale anyway)
6) I don't know what a GROUP BY is

I've also done both DBA and code and I can now look back and laugh at my earliest coding. Every noob does stuff like this.

I have had developers with over 10 years experience (some up to 30 years)

The world is full, not just devs, but the whole world is full, of people who have 60 "first six months" of experience over and over and over. Some folks just never learn.

Re:Legit question

[serviscope_minor]

NoSQL does make developers' lives easier, though, because they don't necessarily have to think about their data in advance,

I've heard claims like these a lot, and I must say that I've never understood them. Programs maniuplate data. I just don't see how you can write a program without knowing about your data. It makes no sense.

Wrong person doing analysis

[aristotle-dude]

"Tech writer (and programmer) Jeff Cogswell examines both sides from a programming perspective."

Irrelevant. The data exists to serve the needs of the business and programmers/developers work to serve those needs. The company should chose the best tool for the job which is a usually a relational database as it serve the needs of the "business" the best in most cases. If you are looking to see which is easier for you then you are a shitty programmer and you need to upgrade your skills to understand how to work with relational databases. You should not be dictating what storage methodology is used for the data.

To be a competent developer, you need to have some understanding of how databases work because you cannot rely on the DBA to babysit all of the projects. You should understand what indexes are, the difference between and inner and outer join and when you can use each time and you should test your code against a large data set to find any bottlenecks on the database side.

ignoring history, are we?

[sribe]

For the past 40-some years, relational databases have ruled the data world.

Bullshit.

In 1972 hierarchical databases ruled the world (with a few network-model attempts here and there) and continued to do so well into the 1980s. In fact, the theory behind relational databases had only been articulated and published in June 1970. In further fact Oracle wasn't founded until 1977, and didn't ship anything until 1979, and they were the first to successfully promote that new-fangled "relational" stuff in a commercial product--prior to that IBM kept it locked up in the lab, except for some very obscure "mostly demo-ware" things, so it wouldn't threaten their then-current cash cow: IMS. IBM's entry into the relational database world, in the early 1980s or so, was a direct response to the growing sales of Oracle.

Also in the 1980s we got: Sybase, Informix, Ingres, MS SQL Server. Then in the 1990s we started getting open-source RDBMSs, along with actually robust versions for Windows-based servers. Then in the 2000s holy crap we even got good database servers on Macs!

Anyways, relational databases have really only "ruled the world" for the past 20 some years ;-)

Huh

[Safety Cap]

Speaking as a professional SQL Developer with OVER TWENTY YEARS of experience, an RDBMS is not the answer to every problem. Sometimes NoSQL makes sense.

For example, if I'm dumping some random user data that will never be formatted/standardized/normalized—that can be different domains for every user—NoSQL might be the right choice.

Maybe I want to store a user's favorite object (puppy, car, toy, steak 'doneness') and I don't want to have a child-table-from-hell lookup table. NoSQL is a great option.

On the other hand, if I want to do some sort of row lookback, then it is far easier in a relational DB. For example, if I want to find the salary average and of all of people in the same department as the most recent new hire or the average working 'lifespan' (how long before the person quits, gets fired or dies) of every department vs. their salary range*, then it is pretty easy.

Now get off my lawn.

* Yes, real-world examples.