3 ms·

" NuoDB is often lumped in with NewSQL databases, which he finds to be an oversimplification. ”SQL is just one personality for us. We can be NoSQL or SQL, the i

" NuoDB is often lumped in with NewSQL databases, which he finds to be an oversimplification. ”SQL is just one personality for us. We can be NoSQL or SQL, the innovation we have is much deeper,” Morris said. He prefers to compare NuoDB to BitTorrent in the way it divvies up tasks to any number of processors — avoiding bottlenecks — but somehow managing to keep all that data organized, accessible and safe." I've been waiting for something like this. NoSQL products took a look at the limitations of SQL DBMS products and (incorrectly) assumed that SQL was the problem. SQL may be a symptom of the problem, but the deeper problem is conflating the logical and physical data model in SQL-based DBMS and also in most NoSQL products. A "record" (however you define it) doesn't need to be mapped 1-to-1 with the physical bits on storage, but for some reason (probably because it's easier) virtually every product does so. It doesn't matter what language you use to access your data, as long as the underlying DBMS operates on solid fundamental principles of data management (ACID, logical/physical orthogonality), you can have an innovative, pleasing-to-use system. Very interested to see what these folks come up with.

Dave_Rosenthal 14y ago
Well put. I'm the co-founder of a database startup called FoundationDB. One of our central philosophies is to decouple the logical data models our product supports from the physical one. In our case, we choose a core data model of an ordered, transactional key-value store, and built layers (http://foundationdb.com/#layers http://foundationdb.com/#layers) from there to expose other data models. However, decoupling the problem this way without true ACID transctions is very difficult. I think this is why there are so many NoSQL databases in the market with so many different data models; without transactions a change to a logical "record" cannot atomically update multiple physical "records" atomically.
jandrewrogers 14y ago
Underneath the hood all database systems contain the same basic elements: an implementation of relational algebra operators and a concurrency control mechanism. Even nominally "non-relational" databases, like graph databases, are built on top of relational operator implementations (you say "graph traversal" and I say "join recursion"). What has traditionally separated the NoSQL databases from the SQL databases is that they implement a smaller subset of relational algebra e.g. the famous lack of join operators. This gave them the latitude to throw out the SQL interface and build interfaces that were more domain specific and a better match for what some applications need to do. Now we are starting to see new databases that are discarding the SQL orthodoxy but with a relational algebra implementation that is as expressive as anything found underneath a conventional SQL database. They could implement SQL if they wanted to but there is less of a compulsion to do so than there used to be. Hopefully this will lead to the best of both worlds.
- MattRogish 14y ago
  "NoSQL" projects have thrown out the relational baby with the bath water and instead implemented their own data model (mostly made-up). The Relational Model is (hugely simplified) predicate logic and set theory combined with logical/physical data independence and integrity. Relational algebra (selection, projection, union, etc.) are important but just a part (very important, of course, as it gives us a sound theoretical foundation to implement from) of the query language. The "Management System" part of the "DataBase Management System" are the constraints, logical/physical representation, data model, etc. - which IMHO represent the bulk of what a DBMS ought to do. What sounds interesting about Nuodb is that they've kept the sound relational fundamentals and created something that is what the relational model has espoused from the beginning. Or so it reads.

Dave_Rosenthal 14y ago

Well put. I'm the co-founder of a database startup called FoundationDB. One of our central philosophies is to decouple the logical data models our product supports from the physical one. In our case, we choose a core data model of an ordered, transactional key-value store, and built layers (http://foundationdb.com/#layers http://foundationdb.com/#layers) from there to expose other data models. However, decoupling the problem this way without true ACID transctions is very difficult. I think this is why there are so many NoSQL databases in the market with so many different data models; without transactions a change to a logical "record" cannot atomically update multiple physical "records" atomically.

jandrewrogers 14y ago

Underneath the hood all database systems contain the same basic elements: an implementation of relational algebra operators and a concurrency control mechanism. Even nominally "non-relational" databases, like graph databases, are built on top of relational operator implementations (you say "graph traversal" and I say "join recursion"). What has traditionally separated the NoSQL databases from the SQL databases is that they implement a smaller subset of relational algebra e.g. the famous lack of join operators. This gave them the latitude to throw out the SQL interface and build interfaces that were more domain specific and a better match for what some applications need to do. Now we are starting to see new databases that are discarding the SQL orthodoxy but with a relational algebra implementation that is as expressive as anything found underneath a conventional SQL database. They could implement SQL if they wanted to but there is less of a compulsion to do so than there used to be. Hopefully this will lead to the best of both worlds.

MattRogish 14y ago
"NoSQL" projects have thrown out the relational baby with the bath water and instead implemented their own data model (mostly made-up). The Relational Model is (hugely simplified) predicate logic and set theory combined with logical/physical data independence and integrity. Relational algebra (selection, projection, union, etc.) are important but just a part (very important, of course, as it gives us a sound theoretical foundation to implement from) of the query language. The "Management System" part of the "DataBase Management System" are the constraints, logical/physical representation, data model, etc. - which IMHO represent the bulk of what a DBMS ought to do. What sounds interesting about Nuodb is that they've kept the sound relational fundamentals and created something that is what the relational model has espoused from the beginning. Or so it reads.