A Year of MongoDB

Re:A Year of MongoDB by jchrisa on Friday May 10, 2013 @01:22PM (#5687473)

Please don't conflate MongoDB and NoSQL. NoSQL is about the right tool for the job. For instance many of our Couchbase customers are very technical and risk averse. They choose Couchbase because other solutions (often MySQL or Oracle) have become the wrong tool for the job, as requirements change.

Mongo is a little different bc they actively position themselves as a MySQL replacement for your average Rails app.

[ Parent | on HN ]

Re:A Year of MongoDB by jeffdavis on Friday May 10, 2013 @01:53PM (#5687653)

"NoSQL is about the right tool for the job."

I never liked that rationale:

* The job almost certainly will change. Data lives a long time, usually much longer than the original application.

* It's likely to conflate marketing claims with actual fitness for a purpose. A special-purpose system with special-purpose marketing may sound great if the special case lines up with what you're doing. But that doesn't mean that it's actually a better fit for that special purpose. And, thanks to confirmation bias, people almost always think their situation does sound like the special purpose for which the system was built.

* A database system is a system, not a tool. A tool is used in a particular instance for a short period of time, the results are obvious, and it's easy to switch tools if one is not working out.

Of course, there are always valid reasons to choose the special-purpose system, and I'm not saying you shouldn't have used Couchbase. I just don't like the "right tool for the job" argument.

[ Parent | on HN ]

Re:A Year of MongoDB by frenchy on Friday May 10, 2013 @03:14PM (#5688118)

I've heard DBA complain that many programmers see data as not all that important: that the data simply exists to run the program. This obviously not the case in any serious real-life environments, but I think it's the sort of attitude that many NoSQL supporters have.

[ Parent | on HN ]

Re:A Year of MongoDB by jchrisa on Friday May 10, 2013 @11:46PM (#5689648)

One thing that become much easier with the JSON document model is sync, which is a valuable abstraction over the network layer. http://blog.couchbase.com/why-mobile-sync

Another thing that you win with the document model is lots of primary key lookups, making it easy to model your data access around your hot path. http://blog.couchbase.com/performance-oriented-architecture

[ Parent | on HN ]

Re:A Year of MongoDB by threeseed on Friday May 10, 2013 @03:59PM (#5688356)

   I just don't like the "right tool for the job" argument.

Then say the "right technology for the task" then.

There is no ONE database that works perfectly in every situation.

[ Parent | on HN ]

Re:A Year of MongoDB by jeffdavis on Friday May 10, 2013 @10:10PM (#5689474)

When installing a database system, it is rarely a "task". It's usually something that will live a long time and there will be many long-term consequences.

[ Parent | on HN ]

Re:A Year of MongoDB by rubinelli on Saturday May 11, 2013 @11:32AM (#5690900)

Back in the day, many startups died with a gigantic Oracle database that cost them months of runway, because they had to "think long-term".

Build for what you need now, and just make sure your "central repository of truth" isn't lossy. You can always replicate for specific use cases later.

[ Parent | on HN ]

Re:A Year of MongoDB by jeffdavis on Saturday May 11, 2013 @01:14PM (#5691276)

I'm not saying that you shouldn't make short-term compromises. I'm saying that "right tool for the job" is sloppy reasoning.

Even in the short term, it might be much faster to develop against a good RDBMS than a nosql system. I think many developers are so focused on "abstracting away the data store" that they forget what a good RDBMS can do for them.

[ Parent | on HN ]