|
|
|
|
|
by FLT8
656 days ago
|
|
The main trouble I have with mongo or document databases in general is that using them effectively requires a lot of design thinking up front. You need to really understand your domain model, in a DDD sense. This isn't usually made clear to people. Document databases are good for working with / storing aggregate root objects and related entities. If you don't know what that means, or are feeling your way through a new domain and aren't in a position to decide if you're really dealing with an aggregate root object or not, or think things might be subject to change later, put the tools down and go with something more conventional. Additionally, if you do use mongo for your operational data store, you should probably consider combining it with read-projections in a relational style DB too, or at least more conventionally defined flattened collections in mongo, in order to service bulk read style queries. Aggregation queries in mongo can get out of control quickly if you're not careful. Much better to plan for that early. And if you end up separating concerns like that, you'll probably find yourself wondering why you didn't just go with Postgres from the start. |
|