Hacker News Reader

Comment by wvenable | Hacker News Reader

> Why are people talking about NoSQL and relational databases as if they're solving the same problems?

If you can switch from one to the other and back again, how are they not solving the same problems?

used to solve a problem != meant to solve a problem

Let's bring up the age-old vehicle analogy. Any vehicle fundamentally solves the the same problem but that's naïve outlook that doesn't acknowledge any specific use-cases. I can drive a truck down the street to get a Coke or ride my bicycle across Canada but that doesn't mean bicycles and trucks are meant to solve the same problem. The differences are obvious when you need to move a pallet of Coke (or 50).

What the stuff is "meant for" is often not important in real life situations.

If you have pallet of Coke to move, a bike and no driving licence that you don't care what the bike was meant for.

If you have to hammer a nail but you only have pilers in your close vicinity you hammer it with pilers and don't care what inventors of pilers meant them for.

I'm not trying to draw any parallels to RDBMS vs NoSQL just pointing out that what often matters in real life is what problems are solved with which tools and why. What the tools were meant for is pie in the sky.

For legacy stuff that's true. For new projects we can and should make better decisions (if politics aren't in the way). Many DB systems are free and open source. If you have Unix servers you can choose from PostgreSQL, MySQL, Cassandra, Riak, CouchDB, MongoDB, Voldemort, etc. There is no reason not to choose the right tool for the job. You can assess them all if you have the time and resources.

It's not the physical world and we basically always have whichever tool we need available to us. I mainly use open source software so that may not be true for everyone I suppose. That's their choice though.

Just because you can pound a screw into the wall with a hammer doesn't mean it solves the same problem as a screwdriver.

And just because you've got a clever saying doesn't mean we aren't just dealing the two different kinds of screw drivers. That's the whole point here.

Just because there's overlap in the problem domains the two classes of tools can be used for does not make them fully interchangeable. If you use a NoSQL tool for transaction processing, you're probably doing it wrong; if you use an RDBMS to house vast amounts of schema-less data, you're probably also doing it wrong. Yes, exceptions exist for every rule, but in the grand Venn diagram of applicability of NoSQL and RDBMSen, there are huge areas that don't overlap. You ignore those areas at your own peril.

In this case, is the data schema-less? They started with a defined schema and maybe now they don't. Your data defines the tool, but you define the data.

I can store JSON in a MySQL column and you'd say I'm using the wrong tool. But I decided to define a schema instead, then I'm using the right tool? It's pretty arbitrary. Some requirements do lean one way or the other but most of the time there's not much of a difference.

The areas where clearly an RDBMS is the correct solution or where NoSQL is clearly the correct solution aren't an issue. I think there are huge areas that do overlap. NoSQL is being advocated in far more situations than just where it's clearly the correct solution.

My point wvenable, is that we are absolutely not dealing with two different kinds of screw drivers here.

Yes they both store "data", but there are types of data that one is well suited to deal with, and alternative types of data that the other one is better for. On my team we've already split out data into two sets, one that lives in ACID RDBMS and one that lives in NoSQL.

If you are dead set in using one solution for everything, my pity for you.

Reply on news.ycombinator.com