> 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.
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.