I think the issue isn't SQL, but the table paradigm for storing data. Humans do not store data in separate tables that need joining, they store data in a fully connected graph (hyper-graph). Its about relationships and hierarchies - the graph allows incredibly fast hierarchical reasoning, as most things involve hierarchical reasoning. The relational table, and Sql by correlation, are terrible at the human approach to working with data especially hierarchies.
> You can simulate noSQL with graph and RDBMS tools - but, again, you shouldn't
What is the feature which makes the noSQL which you shouldn't do in a relational database? To me noSQL always looks like a subset of relational database. The only thing, maybe, is that you can truly put everything in, but with modern JSON features and all the other things I don't see a downside in using relational. (Except a little learning curve, while that can be hidden behind some ORM or something if you really want for the beginning)
What is the thin noSQL brings to the table which a relational system doesn't have? (Except that writing a depth search in a JSON document in SQL is a bit more cumbersome, but if that is a concern that can be wrapped in a data access library to generate the SQL)
But thats just it, having many silos for connected information is just not the way we humans do it, nor necessary. A single conceptually indexed space/time hypergraph (as we humans do it) for any part of the world is all you need, scalable up to many billions of edges for that one part of the world.
having many silos for connected information is just not the way we humans do it
What do you mean? I can think of many silos containing connected information: municipal residence records, marriage registries, birth records, police reports, tax records, medical records (for each hospital) are all silos connected by a citizen's identity.
You missed the "humans" part of my statement. We humans mentally have a fully linked graph (hypergraph) of what we know through space-time and conceptually indexed. We do not have a whole bunch of disconnected data silos in our minds. Modelling the very successful human approach to data and reality modeling may make more sense then using these 50 year old tables and disconnected silos?
There are more recent aspects of SQL that do hierarchical processing well. Graph processing is often decent depending on the particular DBMS. The syntax and conceptualization of these queries is not as well socialized though.
sql doesn't specify how data is stored, it's only a description of the data you want. how your data is connected or not at rest is up to the engine and how you leverage its engine-specific features.
Sort of. "Does not specify" does
not mean there is no connection between logical and physical layers. The relational model has strong implications for what a storage engine should do well.
> The relational model has strong implications for what a storage engine should do well.
agreed, the implication is that the engine should do everything well. rdbms is a product of being pulled in every direction, there's generally an index strategy for everything including fully connected hyper graphs, and that's how they ought to be because we can write wildly complex recursive sql queries and the goal is an efficient ideally optimal execution plan
> agreed, the implication is that the engine should do everything well.
I don't think you mean "everything, equally well".
But if you mean that database vendors feel pressure to have their "RDBMS" be able to "be competitive" across a wide variety of use cases and metrics, I tend to agree.
