I think many teams nowadays tend to choose NoSQL just because of that fancy Medium articles written by some guys wearing Ray-Bans. E.G. Just because it's "cool".
NoSQL is way trickier than one may think. I personally prefer to use NoSQL ONLY with some expressive backup like Clojure or some solid data management stuff happening on the backend. I don't trust those built-in JavaScript interpreters that databases have.
With that being said, I prefer to store entities as a flat structure with ids and fetching them on the backend. This approach won't be efficient if you need to do some data-intensive stuff, but NoSQL wasn't meant to do this in the first place.
If I need master-detail relations, I'll choose SQL because if today you need master-detail relation, tomorrow you'll need the full-blown aggregation from multiple sources.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
How to implement master-detail relation structure in NoSQL?
Good topic to discuss.
I think many teams nowadays tend to choose NoSQL just because of that fancy Medium articles written by some guys wearing Ray-Bans. E.G. Just because it's "cool".
NoSQL is way trickier than one may think. I personally prefer to use NoSQL ONLY with some expressive backup like Clojure or some solid data management stuff happening on the backend. I don't trust those built-in JavaScript interpreters that databases have.
With that being said, I prefer to store entities as a flat structure with ids and fetching them on the backend. This approach won't be efficient if you need to do some data-intensive stuff, but NoSQL wasn't meant to do this in the first place.
If I need master-detail relations, I'll choose SQL because if today you need master-detail relation, tomorrow you'll need the full-blown aggregation from multiple sources.