SQL Vs. NoSQL: Which Is Better? 306
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."
Re:Stupid question (Score:2, Interesting)
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).
^ This.
I am the architect of a NoSQL solution based on Hadoop (and some of its other related projects). The value Hadoop adds to our organization is undeniable ... but so are the traditional RDBMS where we store distilled information from our Hadoop cluster.
an Oracle DBAs perspective (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
Re:Flamebait in Headline (Score:4, Interesting)
The name noSQL itself is flamebait.
But yes, a much more informative article would br: SQL or NoSQL - when to use what.
Re:Stupid question (Score:2, Interesting)
Commercial offerings give you someone to sue when things go bad.
Huh (Score:5, Interesting)
Speaking as a professional SQL Developer with OVER TWENTY YEARS of experience [rationalwiki.org], 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.