NoSQL doesn't mean non-relational, it just means the absence of the Structured Query Language. So why isn't there a NoSQL relational database?
>NoSQL doesn't mean non-relational<p><a href="https://en.wikipedia.org/wiki/NoSQL" rel="nofollow">https://en.wikipedia.org/wiki/NoSQL</a><p><i>A NoSQL (originally referring to "non-SQL" or "non-relational")[1] database provides a mechanism for storage and retrieval of data that is modeled in means other than the tabular relations used in relational databases.</i>
Usrbinbash makes a good point regarding the meaning of “relational”. Many people have come to think that “relational” refers to the relationships between entities in the database, when it really means that the database manages data in tabular form. I think this misunderstanding has become more ingrained because people typically normalize their data in RDBMSs, which necessitates greater use of joins. So, when folks talk about a “relational” workload, they often mean executing ACID-compliant joins over a normalized dataset. Because early NoSQL databases had traded transactional consistency for performance and scalability, there’s been an expectation that NoSQL databases can’t support what some think of as a relational workload.<p>To be fair, in the early days of NoSQL, it was necessary to use denormalization in one’s schema to achieve transactional integrity in the absence of joins. However, distributed databases have since overcome the major challenges of achieving consistency at scale. For example, <a href="http://Fauna.com" rel="nofollow">http://Fauna.com</a> is a serverless, document database which supports ACID transactions via the Calvin protocol. This means that you can execute transactionally consistent joins across collections (“tables”), and either normalize or denormalize your data model for all the same design reasons you might in a traditional RDBMS. The principle difference is that records in Fauna are JSON documents rather than rows in a table.<p>This is not to say that denormalization in modern schema design isn’t beneficial. However, support for ACID joins in a modern document database gives you more latitude in your schema design choices.<p>Full disclosure, I am a Product Manager at Fauna.
(1) Joins are a challenge to implement, particularly if CPU, network, and storage use matter. To get excellent results the database needs a query optimizer that can make a good guess of what query plan will be effective.<p>(2) There are many databases with other query languages that support joins, just a few are<p><a href="https://www.arangodb.com/" rel="nofollow">https://www.arangodb.com/</a>
<a href="https://www.w3.org/TR/sparql11-query/" rel="nofollow">https://www.w3.org/TR/sparql11-query/</a>
<a href="https://docs.couchbase.com/dotnet-sdk/current/howtos/n1ql-queries-with-sdk.html" rel="nofollow">https://docs.couchbase.com/dotnet-sdk/current/howtos/n1ql-qu...</a>
<a href="https://neo4j.com/developer/cypher/" rel="nofollow">https://neo4j.com/developer/cypher/</a><p>all of the above support some combination of document and graph models. All of them can be used in a way very similar to a SQL database. For instance you can stuff arangodb with 'flat' JSON documents that work like tables and also create RDF graphs structured like a relational database and write SPARQL queries.<p>In fact there is a close mathematical relation between SQL and SPARQL and those other query languages. For instance it is possible to write a schema that maps a set of relational databases to an RDF graph, then compile a SPARQL query into a process that runs SQL queries on multiple databases. Better than that the system can rewrite the SQL queries to implement powerful and efficient inference<p><a href="https://www.obitko.com/tutorials/ontologies-semantic-web/owl-dl-semantics.html" rel="nofollow">https://www.obitko.com/tutorials/ontologies-semantic-web/owl...</a><p>The Department of Defense tried this technology to answer the question of "Where does all the money go?" It didn't fail because the math didn't work or the tools sucked but more because of the intrinsic complexity of the problem and politics.
The original Carlo Strozzi "NoSQL" database did exactly what you said.<p>It was an RDBMS.<p>It supported joins.<p>It just didn't use SQL syntax; it used a stream-operator paradigm.<p>Instead of "OUTER JOIN" you used "jointable -al"<p><a href="https://en.wikipedia.org/wiki/Strozzi_NoSQL" rel="nofollow">https://en.wikipedia.org/wiki/Strozzi_NoSQL</a>