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.
The debate between relational and document databases is often treated as a technology choice. Underneath, it is a modeling choice. What is the natural shape of the domain?
Software developer who loves building, learning, and sharing.
Interested in AI, full-stack development, automation, and open-source projects.
Here to exchange ideas, meet great developers, and grow
Location
Philippine
Education
Self-taught developer focused on continuous learning
Pronouns
He/Him
Work
Software Developer building AI-powered applications
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.
We're a place where coders share, stay up-to-date and grow their careers.
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.