Slashdot Mirror

← Back to Stories (view on slashdot.org)

SQL Vs. NoSQL: Which Is Better?

Posted by samzenpus on from the pick-a-side dept.

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

11 of 306 comments (clear)

  1. Flamebait in Headline by Fwipp · · Score: 5, Insightful

    SQL and NoSQL are different, with different use cases.

    1. Re:Flamebait in Headline by medv4380 · · Score: 5, Funny

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

    2. Re:Flamebait in Headline by Anonymous Coward · · Score: 5, Funny

      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.

    3. Re:Flamebait in Headline by Anonymous Coward · · Score: 5, Insightful

      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.

    4. Re:Flamebait in Headline by Dragonslicer · · Score: 5, Funny

      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.

    5. Re:Flamebait in Headline by Sarten-X · · Score: 5, Insightful

      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.

      --
      You do not have a moral or legal right to do absolutely anything you want.
  2. "No" by Anonymous Coward · · Score: 5, Informative

    "No".

  3. Stupid question by adturner · · Score: 5, Insightful

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

  4. MySQL vs MongoDB by djbckr · · Score: 5, Funny

    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

  5. an Oracle DBAs perspective by Anonymous Coward · · Score: 5, Interesting

    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

  6. ignoring history, are we? by sribe · · Score: 5, Informative

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