Over the last decade, MongoDB has been my default database. That default shaped a strong point of view: a large share of application domains can be modeled directly with documents, in a simple way, without an ORM.
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (2)
I found it interesting that the author defaults to MongoDB, as I've had similar experiences where a document database simplified my data modeling. However, I've also encountered cases where complex relationships between entities made a relational database a better fit. I'd love to hear more about how the author handles such scenarios in their document database approach. Do they rely on application-level logic to manage these relationships or use a specific database feature to mitigate this issue?
When working on a data model we control the kind of relationship among entities, so we don't incidentally encounter cases where a relational database is a better fit. if part of the domain is better modeled by relations, then a relational database is to be introduced in the architecture. My article describes some of the cases where that is clearly a better fit. In my experience, those cases are a well defined minority.