7

There's very little good use cases for mongo, change my mind.

Prototyping maybe? Rails can prototype, create/update/destroy db schemas really quickly anyways.

If you're doing a web app, there's tons of libs that let you have a store in your app, even a fake mongo on the browser.

Are the reads fast? When I need that, use with redis.

Can it be an actual replacement for an app's db? No. Safety mechanisms that relational dbs have are pretty much must haves for a production level app.
Data type checks, null checks, foreign key checks, query checks.
All this robustness, this safety is something critical to maintain the data of an app sane.

Screw ups in the app layer affecting the data are a lot less visible and don't get noticed immediately (things like this can happen with relational dbs but are a lot less likely)

Let's not even get into mutating structures. Once you pick a structure with mongo, you're pretty much set.
Redoing a structure is manual, and you better have checks afterwards.

But at the same time, this is kind of a pro for mongo, since if there's variable data, as in some fields that are not always present, you don't need to create column for them, they just go into the data.

But you can have json columns in postgres too!

Is it easier to migrate than relational dbs? yes, but docker makes everything easy also.

Comments
  • 2
    Postgres ends at 5TB working set and at 99.99% availability. If you need more, then you must go NoSQL or do some home-baked sharding. Granted, too many people go into document-based databases, when json columns would be enough.
  • 2
    Mongodb is a document db and while most relational db can store objects its not exactly the same.

    But I have built a commercial app with several hundred users and a million transaction a day.

    My experience is that its does not solve all problems.

    If you prefer a single db use a relational one but some problems are easier to solve with a document db.

    So my recommendation is to try it out to learn but use it only if you can see how it might help.

    I would probably not use it again unless I need to go massive scale.
  • 3
    All the shit you mentioned you need are relational features.
    You simply don't know mongo enough to know where to use it.
  • 1
    I guess the complain refers to developers who used mongo because the hype
  • 0
    @Voxera so is it good for big amounts of data? interesting
  • 1
    @mundo03 you sound like you didn't read properly
  • 0
  • 2
    @erandria if you need to store complex objects but can live with finding by id its good.

    You can easily pull just the parts of the document you need and even update part of it without pulling all data.

    You can do the same with xml in sqlserver but its much more complex syntax.

    And it has pretty easy sharding support to split data over say 20 servers and run queries over them.

    Doing the same with sql server is a bit trickier and require the enterprise edition landing you in the hundreds of thousand of dollar license category instead of mongo db free license ;)

    So for specific purposes mongodb can be a better choice but I would always combine it with a sql server like mssql, postgresql, mysql or mariadb for any relational data or simple table like data.

    But for a profile that is always accessed through the id mono db is very good.

    And with a sql and maybe a graph db for different kinds if relations you can get the best of all :)
  • 0
    @Voxera ok, I will try to have an open mind and see if it ever fits for one my projects...

    btw, sql server is an ms trademark for their relational db software... it's their fault though for using generic terms as trademarks...
  • 2
    @erandria MongoDB ist very special and unique.

    The traditional hype based on the claim that altering data takes long time (in RDBMs) is long gone.... Every RDBMs is heavily investing in solving that riddle.

    A way better use case for Mongo Db is - imho - when your data can and should change, like in reports, aggregated data, document storage (eg storing PDFs, keeping metadata of content indexed) and so on.

    Or - plain and simple - you have tons of data that may or may not change, but (important) are mostly written once and then read (heavy read, rarely updated) - with an SQL ORM oriented API / behaviour

    For everything else. Use RDBMs.

    I don't mean in it in a bad way...

    But....

    Redis - Dump
    MongoDb - Dump with nicely packaged trash
    RDBMs - Dump where every Trash Item has it's own home with streets so they can visit each other.... ;)
  • 0
    @IntrusionCM wow man, very well explained, it does make a lot of sense for reports!
Add Comment