SQL vs. NoSQL Databases: What’s the Difference?

My first real job was doing development on a custom application built entirely in UniVerse[1]. It was a really interesting way to work and mirrors a lot of what the Open Source NoSQL databases do, though it does it differently. Instead of storing the schema with the records (e.g., a JSON document), a record was simply a list of data elements (fields), each field could have multiple values (or not), each value could have multiple subvalues (or not), and there was a lower level that you could go to in order to store multi-line text data.

There was a dictionary attached to each file that primarily drove the query tool. You could also build calculated fields (I-descriptors) to do primitive joins, among other things. If you had a file containing invoices, you might have two fields to list the item number and quantity (these would be repeated for as many items as are on the invoice). You could then use an I-descriptor to follow item number over to the items file and pull the description, price, etc.

The entirety of the application ran within UniVerse. When users logged in to the unix server, their shell would run a script that would set up the environment and fire up UniVerse. The UniVerse LOGIN paragraph would then show a menu system and allow them to do their thing. Everything was written as either a paragraph, roughly equivalent to a shell script that ran UniVerse commands, or a BASIC program. The dialect of BASIC natively understood dynamic arrays, which were a 1:1 match to the structure of the records on disk.

UniVerse also had a built-in way to execute SQL queries against the multivalued data. In the invoice example above, the item number and quantity would be associated in the dictionary. These would then be exposed as another table by the SQL engine. You could go "SELECT A.INVOICENO, B.ITEMID, C.DESCRIPTION, B.QTY FROM INVOICES A, INVOICES_ITEMS B, ITEMS C WHERE A.@ID = B.@ID and B.ITEMID = C.ITEMID" and it would know that INVOICES_ITEMS is really part of the data in INVOICES.

It was a really cool system and I wish there was something like it in the Open Source world. Sadly, development on MaVerick[2] seems to have stalled.

[0] https://en.wikipedia.org/wiki/MultiValue

[1] http://www.rocketsoftware.com/products/rocket-universe

[2] http://www.maverick-dbms.org/

How is SQL side-effect-free if it has INSERT, UPDATE, DELETE?

In a relational database, you have one schema and you have to convert/update your data to match that schema whenever it changes.

I've done one big project many years ago that used NoSQL storage of heterogeneous "document" types -- a perfectly reasonable use-case for the technology -- and I wouldn't do it again. Although at the time it seemed crazy to create different tables to hold this data it would have made that code so much simpler now.

It's also about 50% wrong. Let's just move on.