We usually talk about several paradigms for data management and programming: navigational (e.g. CODASYL, OO databases/languages, most graph DBs), tensor-based (e.g. MOLAP, Matlab, TensorFlow, Pytorch), Map-Reduce (e.g. Hadoop and Spark before they started to disown their MR heritage). Semistructured (e.g. JSON) and dataframes (e.g. Pandas) are also important abstractions. These abstractions can be captured in the relational paradigm — in other words we can think of them as special cases and represent them as views on relational models.
It is clear from the last 50 years of our industry that the relational paradigm (eventually) always wins. It wins because it separates the what from the how and automates away a bunch of tricky programming that we have to do with the more imperative paradigms.
— the OLTP workload was originally supported by navigational systems and then switched to relational systems mostly based on 3rd normal form schemas
— the OLAP workload was originally supported by multi-dimensional array (tensor) systems then switched to relational systems based on star and snowflake schemas
— the Big Data workload was originally supported by map-reduce systems then switched to relational systems based on star/snowflake + JSON schemas.
I believe that the Graph (via navigational), Reasoning (via procedural), and ML (via dataframe and tensor) workloads will move to relational systems based on graph normal form (GNF) schemas. Those relational systems won't be built like the SQL-based systems of today. They will need new relational language extensions, new semantic optimizers, new optimal join algorithms, materialized views that are maintained efficiently, new data structures, etc. We are working on such a system at RelationaAI. We’re in limited preview now but hope to have an open preview by early next year.
> It is clear from the last 50 years of our industry that the relational paradigm (eventually) always wins
You cannot make a foreign key to link two different tables with RDBMSes. It requires to make another table. With graphs instead this is easy, just make a link from/to any node.
With RDBMSes the schema is fixed.
With RDBMSes you cannot have "metaproperties" (or properties about properties). With graphs you can easily say {caesar born{source "foobar"} "100BC"}. With RDBMSes this quickly becomes a mess to handle when you have more properties.
These are just some use cases why relational does not always win.
SQL 99 only requires support for linear recursion, i.e. "each FROM has at most one reference to a recursively-defined relation". Datalog doesn't have such a restriction
It is clear from the last 50 years of our industry that the relational paradigm (eventually) always wins. It wins because it separates the what from the how and automates away a bunch of tricky programming that we have to do with the more imperative paradigms. — the OLTP workload was originally supported by navigational systems and then switched to relational systems mostly based on 3rd normal form schemas — the OLAP workload was originally supported by multi-dimensional array (tensor) systems then switched to relational systems based on star and snowflake schemas — the Big Data workload was originally supported by map-reduce systems then switched to relational systems based on star/snowflake + JSON schemas.
I believe that the Graph (via navigational), Reasoning (via procedural), and ML (via dataframe and tensor) workloads will move to relational systems based on graph normal form (GNF) schemas. Those relational systems won't be built like the SQL-based systems of today. They will need new relational language extensions, new semantic optimizers, new optimal join algorithms, materialized views that are maintained efficiently, new data structures, etc. We are working on such a system at RelationaAI. We’re in limited preview now but hope to have an open preview by early next year.