Data with multiple entities that have a relationship between each other. Take a website that has users, posts and comments, for example. Users have many posts and many comments, posts have many comments and one user.
Got it: I consider different objects or entities stored, indexed, and queried separately but with references to each other in the form of identifiers to really just be sound design. Relational data models typically come with more constraints that inhibit classes or online data mutations and scalability choices. I think it's easy to conflate multiple sets of tradeoffs.
The deepest question is whether it's useful to be able to model the world with first class structure in the form of embedded arrays and embedded sub structures that can be richly indexed. Does this involve certain forms of denormalization? Sure but do tables really represent how you think about the world?
> Sure but do tables really represent how you think about the world?
It's not about "how you think about the world", but how you intend to use this data.
Following my previous example, if you're building a blog you know you'll need to show a post along with its author, or that you'll need to filter posts by author, or maybe show only comments by verified users, etc.
Of course you can also structure your data this way on mongo, since over time they've added tools to support it, but it still feels like a feature tacked onto it rather than something "native" as it is with SQL.
Now, I understand what you're saying about my concept of relational being just a form of design and not inherent to the data itself. That's interesting indeed and I haven't thought about it this way before.
Think about an author for a moment: do you want to model all authors with the same set of columns? Might there be a different set of attributes for a current events journalist and a short story writer? Would you not want to describe certain author attributes in terms of lists of attributes and enable filtering/querying on these easily? This is what a flexible/heterogeneous model with first class support for embedded documents and arrays gives you.
I always struggle to think of you would ever want NoSQL to represent data. The benefit of NoSQL is... lack of schemas? Why would you want this except with unstructured user-generated content (which then will need to be structured later to be useful)?
I think there are may be some misconceptions here. There's always a schema. It's about flexibility and heterogeneity of the schema shape and evolution over time
Yes I can change a RDBMS schema over time quite easily. I'm being honest - why is a NoSQL DB better for general purposes? I am a longtime CTO and I have yet to figure this out.
In an RDBMS a schema change is both an application tier change and database tier data definition change and depending on what you want to optimize for that can be a material difference in terms of agility. Anything can be described as "quite easily" but in a fundamental sense if a change requires you to reason and initiate at two layers and that change often requires downtime, you have a major impediment on your hands. You might also call slowing down a feature. I think it's a bit like fiat vs Crypto, there's a religious ferver aspect that drives some people to declare a position on this and a set of tradeoffs aspect.
