3 ms·

In my experience many domains that seem document-oriented suddenly reveal themselves as relation-oriented as soon as you start building.

nevi-me 6y ago
This goes both ways to an extent. Any data that you can model in Mongo, can be modelled in a SQL database. There's often the argument that documents aren't structured, but in many cases, there's structure if you categorise them well. If one is storing truly randomly-structured records in a document-database, I would question why, as they could store the documents as files instead. The other way is that you could store documents that fit a relational structure, into a document-store. It depends on use-cases, and those use-cases exist and are valid. We can store KV structures in a SQL database, but we're seeing projects using Cassandra and co.
- arcturus17 6y ago
  You can indeed model relational domains using document stores, but soon you'll start having keys everywhere to glue the different documents together. This may not be that big of an issue if you have a few different types of entities and you're not keeping that many relationships between them. But you're still going to face problems when you need to change the relationships, an issue which is trivial to resolve in a relational DB. If there are more than a few relationships and they're even just moderately unstable, you've probably made a critical mess of the application.
- acdha 6y ago
  > We can store KV structures in a SQL database, but we're seeing projects using Cassandra and co. I think a key difference here is illustrative: you typically only see that when the problem is well understood to need the characteristics of those specialized KV stores and were willing to pay the costs of working with those trade-offs. In contrast, Mongo was overwhelmingly favored people who were speculating about problems they might have without much experience supporting that call. Usually they never actually came close to that level, likely because they were spending their time on the much harder problem of trying to build SQL database semantics into their application instead of working on their business. The key lesson I drew is the powerful value of sticking with proven tools unless you know you can’t. Reading about things FAANG work is cool but people cost themselves a lot by not asking how many orders of magnitude separate their workload and team size from yours.
- collyw 6y ago
  I have experienced the worst of both worlds. Storing JSON documents in a text field in MySQL (the version used didn't yet support JSON), and at my current place we are using Mongo for relational data. :(

nevi-me 6y ago

This goes both ways to an extent. Any data that you can model in Mongo, can be modelled in a SQL database. There's often the argument that documents aren't structured, but in many cases, there's structure if you categorise them well. If one is storing truly randomly-structured records in a document-database, I would question why, as they could store the documents as files instead. The other way is that you could store documents that fit a relational structure, into a document-store. It depends on use-cases, and those use-cases exist and are valid. We can store KV structures in a SQL database, but we're seeing projects using Cassandra and co.

arcturus17 6y ago
You can indeed model relational domains using document stores, but soon you'll start having keys everywhere to glue the different documents together. This may not be that big of an issue if you have a few different types of entities and you're not keeping that many relationships between them. But you're still going to face problems when you need to change the relationships, an issue which is trivial to resolve in a relational DB. If there are more than a few relationships and they're even just moderately unstable, you've probably made a critical mess of the application.
acdha 6y ago
> We can store KV structures in a SQL database, but we're seeing projects using Cassandra and co. I think a key difference here is illustrative: you typically only see that when the problem is well understood to need the characteristics of those specialized KV stores and were willing to pay the costs of working with those trade-offs. In contrast, Mongo was overwhelmingly favored people who were speculating about problems they might have without much experience supporting that call. Usually they never actually came close to that level, likely because they were spending their time on the much harder problem of trying to build SQL database semantics into their application instead of working on their business. The key lesson I drew is the powerful value of sticking with proven tools unless you know you can’t. Reading about things FAANG work is cool but people cost themselves a lot by not asking how many orders of magnitude separate their workload and team size from yours.
collyw 6y ago
I have experienced the worst of both worlds. Storing JSON documents in a text field in MySQL (the version used didn't yet support JSON), and at my current place we are using Mongo for relational data. :(