5 ms·

Currently using MongoDB on a project and boy do I just hate it. We have highly relational data that is a nightmare to reason with and query. Guess what? We also

Currently using MongoDB on a project and boy do I just hate it. We have highly relational data that is a nightmare to reason with and query. Guess what? We also have migrations! It's hard to explain why, but I just get a bad feeling in my tummy every time I have to interact with the database. Just not enjoyable to work with at all. The only thing I've seen it do that actually impresses me is the aggregation framework/pipeline. That's actually pretty neat, and I feel like it's a good fit for the data we're querying with it (analytics data). Other than that, man, I wish I was using PostgreSQL...

tjr 13y ago
We have highly relational data How did your project end up selecting MongoDB? That seems like exactly the sort of thing that it's not good for. (I'm not just being rhetorical; were there other attributes of MongoDB that made it seem preferable to a relational database earlier in the project?)
- woah 13y ago
  When you really start looking into it, what projects actually are good for Mongo? EDIT: It's nice and quick for prototypes. Ironically, I'm building one with it now.
  - boomzilla 13y ago
    After a few months dealing with a system that's built on Mongo ad the data store, I've come to the conclusion that MongoDB only use cases are: 1. A persistent cache, or a compute-ahead read-only data store. 2. A write-only store for high volume but non-critical data, such as comments, log events, etc. MongoDB should never be the primary source of truth data store. Nothing can replace a relational DB for that purpose, yet.
    - vinceguidry 13y ago
      > 1. A persistent cache, or a compute-ahead read-only data store. Even then, you're probably better off with Redis or memcached. > 2. A write-only store for high volume but non-critical data, such as comments, log events, etc. Just write to disk. It's very hard to beat flat file text for this use case and most of the time it's not worth it.
    - bsg75 13y ago
      > compute-ahead read-only data store Definition? As in pre-aggregated data, i.e. materialized views or summary tables?
- themckman 13y ago
  It was simply a matter of joining the project after the decision had been made, unfortunately.
  - andrewflnr 13y ago
    OK, but how did they decide on Mongo before you got there?

tjr 13y ago

We have highly relational data How did your project end up selecting MongoDB? That seems like exactly the sort of thing that it's not good for. (I'm not just being rhetorical; were there other attributes of MongoDB that made it seem preferable to a relational database earlier in the project?)

woah 13y ago
When you really start looking into it, what projects actually are good for Mongo? EDIT: It's nice and quick for prototypes. Ironically, I'm building one with it now.
- boomzilla 13y ago
  After a few months dealing with a system that's built on Mongo ad the data store, I've come to the conclusion that MongoDB only use cases are: 1. A persistent cache, or a compute-ahead read-only data store. 2. A write-only store for high volume but non-critical data, such as comments, log events, etc. MongoDB should never be the primary source of truth data store. Nothing can replace a relational DB for that purpose, yet.
  - vinceguidry 13y ago
    > 1. A persistent cache, or a compute-ahead read-only data store. Even then, you're probably better off with Redis or memcached. > 2. A write-only store for high volume but non-critical data, such as comments, log events, etc. Just write to disk. It's very hard to beat flat file text for this use case and most of the time it's not worth it.
  - bsg75 13y ago
    > compute-ahead read-only data store Definition? As in pre-aggregated data, i.e. materialized views or summary tables?
themckman 13y ago
It was simply a matter of joining the project after the decision had been made, unfortunately.
- andrewflnr 13y ago
  OK, but how did they decide on Mongo before you got there?