The fact that a lot of relational databases now offer document storage does lend credence to the idea, but at the same time you lose so much when you only have document storage
But if you’ve planned your app through and know beforehand you don’t need relational data, you can skip the overhead of a RDBMS.
At least that’s what I would say if I hadn’t been in this exact situation and it later turned out we do need relational data so we had relational documents.
Also working with MongoDB without ODM is pure pain.
Cache-like storage, private user-specific data, blobby or otherwise schemaless data. Stuff like that. But IMO it’s a matter of time until you find a need to operate against this data relationally, and then you regret using document storage. I’ve made this mistake twice now and do not intend to make it again. I now consider document storage architecture to be a performance optimization with significant tradeoffs, and not a choice to be made by default for nearly any scenario.
My reason asking is because there are other scheme I feel are more adequate for non relational data, but this isn’t my domain and I barely dabbled in that, so that’s worth absolutely nothing.
But your point about the data being used later makes a lot of sense and I didn’t think about that. Down the road, someone will ask you to create links to your data and if you already have a DB, then you don’t have to change the whole infrastructure to accommodate that. You can create new schemes and already have a somewhat functional access to it.
The fact that a lot of relational databases now offer document storage does lend credence to the idea, but at the same time you lose so much when you only have document storage
But if you’ve planned your app through and know beforehand you don’t need relational data, you can skip the overhead of a RDBMS.
At least that’s what I would say if I hadn’t been in this exact situation and it later turned out we do need relational data so we had relational documents.
Also working with MongoDB without ODM is pure pain.
Side tracking here : to me, it seems like every DB is relational, no?
What use case would a DB used and not be relational? With my minimal experience in DB, I haven’t seen any other use cases than a relational DB.
Cache-like storage, private user-specific data, blobby or otherwise schemaless data. Stuff like that. But IMO it’s a matter of time until you find a need to operate against this data relationally, and then you regret using document storage. I’ve made this mistake twice now and do not intend to make it again. I now consider document storage architecture to be a performance optimization with significant tradeoffs, and not a choice to be made by default for nearly any scenario.
My reason asking is because there are other scheme I feel are more adequate for non relational data, but this isn’t my domain and I barely dabbled in that, so that’s worth absolutely nothing.
But your point about the data being used later makes a lot of sense and I didn’t think about that. Down the road, someone will ask you to create links to your data and if you already have a DB, then you don’t have to change the whole infrastructure to accommodate that. You can create new schemes and already have a somewhat functional access to it.
Thanks for the input.