NoSQL v. SQL is the worst holy war ever.

http://www.deserettechnology.com/journal/?p=44

by cookiecaper • 16 years ago

87 57 16 years ago

rbranson• 16 years ago

The whole idea with "NoSQL" is that you pick the best tool for the job. Most people that push RDBMS solutions try to shoehorn an RDBMS for every possible scenario. For modeling the majority of business data, an RDBMS is fine. There are many problems such as graphs, logs, lossy real-time data, etc that CAN be modeled in an RDBMS but shouldn't be.

dasil0032• 16 years ago

I largely agree with this, but in my mind using an RDBMS for a sub-optimal task is not always shoehorning—it can be a powerful hedge. In an early stage startup you don't know what the final business model is going to be, or how your data will need to scale. Spending time researching and setting up optimized data stores for things that change drastically or never end up being important is a tremendous waste of time.

shpxnvz• 16 years ago

I suppose it could also be said that spending time designing relational schemas that will change drastically, then migrating data every time they do, is wasteful. Many non-relational databases allow quite a bit of flexibility in terms of incrementally changing structure as you learn about your business needs.

Not that I am in one camp or the other. We use both relational and non-relational databases where it makes sense. The more of each (both in choices and users), the better, so far as I am concerned.

cookiecaper• 16 years ago

>Most people that push RDBMS solutions try to shoehorn an RDBMS for every possible scenario.

I don't think that's true for well-informed developers in a space where NoSQL is acceptable.

It might be true generally only in the sense that most developers don't know or care about NoSQL and don't like the idea of learning something new. That's to be expected; most of these guys will never leave .NET/Java and the blessed toolkits associated with each. They are corporate programmers and they don't really count.

A well-informed person might make some good social arguments against NoSQL adoption, like the lack of experienced available developers, or the relative immaturity of the respective codebase, or other issues that surround emerging platforms. These arguments will sometimes hold merit.

Otherwise, I don't know why one would be averse to the implementation of a "NoSQL" datastore for information like logs. I know that I've always having logs in the relational db.

I haven't met many experienced, decent developers who shun NoSQL when there is a good technical and environmental atmosphere for its implementation. I don't think it's a widespread thing.

leftnode• 16 years ago

Exactly, it's a silly "holy-war" because you can use both quite effectively, both have their place.

jasonkester• 16 years ago

  The whole idea with "NoSQL" is that you pick the best tool for the job.

Stop it. You're doing it again.

The whole idea of "Computer Programming" is that you pick the best tool for the job. It has nothing to do with NoSQL.

markkanof• 16 years ago

That's a really good point. Saying that NoSQL is about picking the right tool for the job makes it easy to dismiss. There are lots of programmers out there that just refuse to look at any other tools than the very small set that they already know. I think it would be beneficial to change that attitude across the spectrum of programming tools.

Groxx4• 16 years ago

NoSQL is primarily a reaction to the ubiquitousness of relational DBs. It's providing another tool aside from a hammer.

anamax• 16 years ago

> Most people that push RDBMS solutions try to shoehorn an RDBMS for every possible scenario.

That's true of Java, garbage collection, FPGAs, and every other type of computer technology.

It may be a consequence of turing completeness.

pw0ncakes• 16 years ago

I'm going to declare something else the worst holy war ever.

Then we can have an even worse holy war than ever was before, making ourselves both wrong.

nostrademons• 16 years ago

I think the Crusades were the worst holy war ever.

There. Problem solved. Unless you wanna kill a few hundred thousand people and go to war for a few hundred years.

(If I'd said "The holocaust", I could've Godwinned this thread, but that wasn't really a holy war.)

arethuza• 16 years ago

That's quite an interesting point - if you restrict holy wars to the "my imaginary friend is better than your imaginary friend.... fight!" kind then you are probably correct.

I'm trying to think of other real "holy wars" - the 30 Years War is perhaps the only other major one I can think of. I guess most other "holy wars" are really justs lingering fall out from conquests Ottoman invasion of Europe, Ireland, .....

viraptor• 16 years ago

Does "War on terror" count as a holy war? Then we could have a contest after all. It's not a few hundred years yet, but give it some time to unfold ;)

berntb4• 16 years ago

Interesting... how were the Crusades larger/worse than the muslim expansion all the way to Spain/Balkan/India?

(Let us bunch the Crusades as one single example, at least for this argument.)

(The Huns/Mongols were religiously tolerant and motivated by conquest, right?)

maurycy• 16 years ago

The worst holy war would be a holy war about holy wars: which holy war is the worst?

Groxx4• 16 years ago

I declare "O rly?" vs "Ya rly" the worst holy war ever.

Neither side will ever give an inch, and vast armies of anonymous have lobbed internets at each other, killing a few StarCraft players in Korea and memeing millions upon millions more, with more arriving every day.

hartror• 16 years ago

What it boils down to is choose the right tool for the job and sometimes that means using two tools that do similar things. I for one won't be giving up SQL any time soon but also look forward to replacing some of our poorly performing sections with NoSQL (we sort of already do thanks to memcache).

dasil0032• 16 years ago

NoSQL is designed to address a certain problem space and RDBMS is designed to address another.

I don't see it that way at all.

It's more like RDBMS is the all-purpose data store that attempts to distill the maximum number conceivable data storage, integrity constraints and lookup requirements into a set of powerful primitives. And NoSQL is a large group of technologies that are each optimized for specific cases which SQL is traditionally bad at, but which don't necessarily have much in common with each other.

bphogan5• 16 years ago

I agree with this, but I'd add that we developers tend to make an RDBMS do everything because it's what they're familiar with. NoSQL is an alternative to solve a specific problem, but you can't see that problem if you're ignorant of it.

It's like my experience with SVN vs Git. I didn't know how useful and more efficient my workflow would be if I used branches, so I never saw why Git was useful. Sure I could branch in SVN, but it was way more work. I got involved in a project where I had to use git, and I learned how branching works, and now I use it all the time because I understand where it's applicable.

I don't think you have to choose MySQL over MongoDB. I think you could be very happy using both, each for its purpose. You don't always know why you need something until you need it. It's always good to keep an eye on what others are doing.

wvenable• 16 years ago

The same argument about branches in source control can made about SQL itself. In my opinion, a large number of developers don't know how to code SQL properly and a lot are afraid of it. They end up using an RDBMS as nothing more than a dumb bit bucket -- often hidden behind increasingly complex abstractions. The NoSQL movement, unintentionally, lets these programmers feel superior about their lack of knowledge.

I don't want to argue against the legitimate use of NoSQL solutions. I just don't think there are enough use-cases to justify the hype. For example, an article was posted here last week about using NoSQL solution to store e-commerce orders.

lucifer• 16 years ago

"SVN vs Git"

An excellent comparative case in point that in my opinion actually undercuts what you are asserting.

You do not lose features and functionality in that transition (where as noSQL is by design reductive), and further, Git is a replacement for SVN and not a complementary tool.

xbryanx• 16 years ago

The first comment on that post is quite hilarious.

Legion• 16 years ago

I don't know. I think any holy war in which people aren't killed is pretty good as far as holy wars go.

kmuzykov5• 16 years ago

Recently I've researched all NoSQL databases(grpaph oriented to be precise). We're building a project which I think fits best in NoSQL solution. And I did not find any suitable solution. Either it doesn't a have client api(we're using .NET) other then REST or plain TCP/IP (and of course I don't have time to create my own API) Either this is just some project more like a school homework.

Do you seriously believe that you can rely your business solution which will run across dozen of PCs on someones experiment?

kmuzykov5• 16 years ago

Another problem is deployment, if I adopt some RDBMS system to my needs, then I already have a bunch of web hostings supporting this type of DB or I can use installer to deploy the DB, run a few scripts and everything is ready to run.

bphogan5• 16 years ago

Deployment isn't the issue with these - deployment can be automated just as easily as an RDBMS. Sometimes easier. It's trivial to throw up several instances of MongoDB for example. As for hosting solutions that support this stuff, well, I prefer VPSs that I control to shared hosting with Mysql for anything that's serious.

But you and I appear to have very different needs.

warfangle• 16 years ago

Deployment with, e.g., Neo4J involves simply telling the Neo4J library which path to use for its binary data files at initialization time. It finds a DB if it's there and uses it, otherwise it creates it. Applicable line of code from their wiki:

  GraphDatabaseService graphDb = new EmbeddedGraphDatabase( "var/graphdb" );

Of course, Neo4J is an embedded solution. It's quite different than using a separate server application.

bphogan5• 16 years ago

I don't understand the problem with the client apis. If you're working with .net, you should have access to an xmlhttprequest library. Building and reading xml to talk to a REST api shouldn't require a specific API library. Unless of course you're just looking to avoid that step altogether and would rather just point, click, drag, and drop and get on with it.

kmuzykov5• 16 years ago

REST is too heavy for my needs. It generates a lot of traffic.

simonw2• 16 years ago

I actually think this says something interesting about .NET v.s. open source platforms. The new batch of NoSQL products are being developed almost exclusively in the open source world - they're written to run on *nix (Windows support, if it exists at all, is generally an after thought) and the client libraries that ship with them target the open source languages first. In this particular case, it feels like closed-source platforms are second class citizens.

I'll hazard a guess that one reason for this is that NoSQL systems are mainly designed for scalability, and free operating systems are significantly cheaper to scale than platforms with a license fee per node.

kmuzykov5• 16 years ago

Then this new holy war boils down to an good old *nix vs windows holy war, or open-source vs closed applications.

Raphael_Amiard• 16 years ago

I can't help but see this post as the blog equivalent of the guy trying to keep people from fighting in the real life, at the same time trying to draw attention to him, and at how mature he is.The article has almost no content at all.

thibaut_barrere2• 16 years ago

I have that wish for humanity: I'd really like people to use words that are in proportion with what they describe.

Things like: "we're dead" (when we just talk about loosing a contract or even closing one company), "it's totally catastrophic" (when someone cannot make it to a meeting, or the vegetables you had planned for dinner are not available anymore at the groceries).

Come on.

Talking about "worst holy war" for tooling trends - sorry, not for me, even for the purpose of creating a catchy headline or of underlining a point.

Oh and yes: I use both NoSQL and SQL, sometimes in conjunction in the same system.

coderdude• 16 years ago

>I use both NoSQL and SQL, sometimes in conjunction in the same system.

As any sane developer would, and without having to go all-or-none either which way. I don't understand the people who are balls to the wall for either side. They both have a purpose.

thibaut_barrere2• 16 years ago

The fights around "tech X is better than tech Y" usually boil down to some kind of fear (of being replaced, of loosing the job) or biaised-validation of all the effort already invested in X.

halostatue• 16 years ago

I think the article used "worst holy war" in the sense of "lamest". The (No)SQL "holy war" is just as dumb as any other computer-related "holy war" throughout our industry's short history (e.g., emacs/vi, Windows/Mac/Linux/Unix). It's as dumb as the arguments about who the best Captain of the Enterprise was.

brettbender• 16 years ago

It's as dumb as the arguments about who the best Captain of the Enterprise was.

Exactly. Everyone knows it was Patrick Stewart.

MicahWedemeyer• 16 years ago

Best explanation I've heard so far: NoSQL = "Not Only SQL" Pick the right tool for the job.

haberman• 16 years ago

> Relational databases scale. NoSQL databases scale.

This is simply not true, if we're talking about horizontal scalability (which is probably the most relevant kind of scaling these days, because it's the most cost-effective).

You can't add more nodes to an RDBMS, keep ACID, and get linear scalability. You just can't.

From what I know of CouchDB, you could scale it linearly if you manage the partitioning of data yourself according to load. But if your data distribution changes you're a bit screwed. My impression though is that most people just use CouchDB on a single machine.

For BigTable, on the other hand, it really is just a matter of adding or removing machines at any time and getting nearly linear scaling. The load is dynamically balanced between machines, so this is actually practical.

Are there ways of scaling an RDBMS architecture? Yes, but they involve giving up ACID (like having read-only replicas, for example).

So I'm not saying RDMBS's are bad, just that there is a real limitation here.

adamilardi• 16 years ago

This holy war seems to just be in the open source world. I really don't see cio's rushing to get rid of oracle/db2/sql server

NoSQL v. SQL is the worst holy war ever.

Related Stories