3 ms·

From my experience, as soon as you need some kind of relation with Mongo, you end up writing more application logic to create and maintain your relations. This

by dmak 13y ago

From my experience, as soon as you need some kind of relation with Mongo, you end up writing more application logic to create and maintain your relations. This probably means you should move to a relational database. For Mongo specifically, can anyone share a pragmatic use case where you did not run into problems with duplication?

jzwinck 13y ago
One example is logs. People have logs, and lots of them. They're usually semi-structured (hopefully there is at least a timestamp and topic and severity in each record). You can put them in MongoDB, and relations are probably not a big concern.
- digitalzombie 13y ago
  Elasticsearch or Solr would be better than Mongodb for Logs. Hell if you actually care about your log and want to search it use Solr or Elasticsearch NOT Mongodb. If you want to store even more data just use Cassandra and index it with Solr or Elasticsearch. Cassandra have faster write than read, it's perfect for logs. You can decentralize logging system too, there are architecture layout out there with elasticsearch and such (example: https://medium.com/what-i-learned-building/e855bc08975d https://medium.com/what-i-learned-building/e855bc08975d). MongoDB is a poor choice, in general for anything in my personal opinion.
philbo 13y ago
Not sure if it counts as a pragmatic use-case, but here's my example. I recently built a little webapp [1] to send email reminders about repositories that you've starred on GitHub. The motivation for it being that I have hundreds of starred repos on GitHub and can't remember what most of them are. Anyway, there is one thing I need to store in that database, users. Nothing else needs to be saved. You can accurately characterise it is a toy application that I built for fun rather than profit. But there are lots of those around and Mongo is often a good fit. If I don't need complex schemata or a huge dataset, why would I choose something else that is less easy to manage? [1] https://githubreminder.org/ https://githubreminder.org/

by dmak 13y ago

jzwinck 13y ago

One example is logs. People have logs, and lots of them. They're usually semi-structured (hopefully there is at least a timestamp and topic and severity in each record). You can put them in MongoDB, and relations are probably not a big concern.

digitalzombie 13y ago
Elasticsearch or Solr would be better than Mongodb for Logs. Hell if you actually care about your log and want to search it use Solr or Elasticsearch NOT Mongodb. If you want to store even more data just use Cassandra and index it with Solr or Elasticsearch. Cassandra have faster write than read, it's perfect for logs. You can decentralize logging system too, there are architecture layout out there with elasticsearch and such (example: https://medium.com/what-i-learned-building/e855bc08975d https://medium.com/what-i-learned-building/e855bc08975d). MongoDB is a poor choice, in general for anything in my personal opinion.

philbo 13y ago

Not sure if it counts as a pragmatic use-case, but here's my example. I recently built a little webapp [1] to send email reminders about repositories that you've starred on GitHub. The motivation for it being that I have hundreds of starred repos on GitHub and can't remember what most of them are. Anyway, there is one thing I need to store in that database, users. Nothing else needs to be saved. You can accurately characterise it is a toy application that I built for fun rather than profit. But there are lots of those around and Mongo is often a good fit. If I don't need complex schemata or a huge dataset, why would I choose something else that is less easy to manage? [1] https://githubreminder.org/ https://githubreminder.org/