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."
Flamebait in Headline (Score:5, Insightful)
SQL and NoSQL are different, with different use cases.
One doesn't have to be "better" (Score:2, Insightful)
Well, at least not better overall. Each solution may be more suited to solving a particular problem. You can also use both, or neither!
Stupid question (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).
Re:Flamebait in Headline (Score:5, Insightful)
"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".
Dumb question (Score:5, Insightful)
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:Flamebait in Headline (Score:4, Insightful)
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.
The answer to all "Which is better" questions... (Score:5, Insightful)
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."
Re:Flamebait in Headline (Score:5, Insightful)
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 (Score:5, Insightful)
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:Legit question (Score:5, Insightful)
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 (Score:4, Insightful)
"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.
Re:Dumb question (Score:4, Insightful)
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.
Re:Flamebait in Headline (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.
Re:an Oracle DBAs perspective (Score:5, Insightful)
Let me put in the "answers" you probably get from noob programmers. ... I donno some workplaces need employee drug testing?
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)
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:Flamebait in Headline (Score:5, Insightful)
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:Stupid question (Score:5, Insightful)
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).
Re:Flamebait in Headline (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.
Re:Flamebait in Headline (Score:4, Insightful)
In that case, I think the answer to "what is the greatest tool?" would be "the person asking the question".