4 ms·

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 ave

by jchrisa 13y ago

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.

jeffdavis 13y ago
"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.
- frenchy 13y ago
  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.
  - jchrisa 13y ago
    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 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 http://blog.couchbase.com/performance-oriented-architecture
- threeseed 13y ago
  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.
  - jeffdavis 13y ago
    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.
    - rubinelli 13y ago
      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.
      - jeffdavis 13y ago
        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.

by jchrisa 13y ago

jeffdavis 13y ago

"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.

frenchy 13y ago
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.
- jchrisa 13y ago
  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 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 http://blog.couchbase.com/performance-oriented-architecture
threeseed 13y ago
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.
- jeffdavis 13y ago
  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.
  - rubinelli 13y ago
    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.
    - jeffdavis 13y ago
      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.