5 ms·

One fun fact: MUMPS had an early "NoSQL" precursor key-value storage engine (the "M" database), that could be directly accessed as if it were a global variable.

One fun fact: MUMPS had an early "NoSQL" precursor key-value storage engine (the "M" database), that could be directly accessed as if it were a global variable. "The M database is a key-value database engine optimized for high-throughput transaction processing. As such it is in the class of "schema-less", "schema-free," or NoSQL databases. Internally, M stores data in multidimensional hierarchical sparse arrays (also known as key-value nodes, sub-trees, or associative memory). Each array may have up to 32 subscripts, or dimensions. A scalar can be thought of as an array element with zero subscripts. Nodes with varying numbers of subscripts (including one node with no subscripts) can freely co-exist in the same array." [1] I had to work with MUMPS once in the past when I was working in the green-screen world in healthcare. I also had to work with Pick/D3 and Basic. It was kind of nice to start there, then move to relational databases, and then see the world get excited again in older models of databases with the NoSQL movement (albeit, much more scalable and distributed). [1] https://en.wikipedia.org/wiki/MUMPS https://en.wikipedia.org/wiki/MUMPS

jacquesm 10y ago
> MUMPS had an early "NoSQL" precursor key-value storage engine (the "M" database), that could be directly accessed as if it were a global variable. Yep. And then there were the clustering primitives allowing you to modify variables on other machines. Which takes 'global state' to a wholly different level. You thought it was problematic that a function could change a global variable as a side effect. Wait until you have to debug that global variable changing out from under your feet by a program running on a machine half the continent away.
rnprince 10y ago
Yeah, MUMPS was pretty prescient in this way. As someone who's experienced the changes first-hand, what do you feel are the most important NoSQL developments since MUMPS? Do you have a preference on NoSQL vs relational databases?
- sixdimensional 10y ago
  Well, this is my opinion. The latest generation of NoSQL databases really tried to add to the distributed / scalability story of databases, as well as provide simpler "input", "output" and "storage mechanisms". This, often at the cost of a degree of ease of use of query languages to be able to easily analyze data. As NoSQL movement started to come into focus, folks saw that the then dominant traditional relational / ACID model was not scaling to internet scale (too many JOINs, too hard to do ACID at that size or not needed, etc.). In reaction to "internet scale", the search turned to finding new or innovative alternatives to the relational model (which really, just represented what was the state of the art at the time). This is how we got BASE instead of ACID, and went back to key-value.. or document-oriented.. or graph-based... or Hadoop/Map-Reduce, etc. People exploring lots of alternatives. I think people mentally "threw relational databases out" for a while as quickly as they threw out the other alternatives (the precursors to relational databases), when relational databases came along. Many have found it hard to live without relational databases. I think modern NoSQL databases try to maximize on input/output/storage and distribution / MPP of data. By now, they give some more expressiveness for query (like MongoDB, Cassandra, Hive/Impala in the Hadoop world), although SQL still beats them in my opinion for ease of use. SQL also could have advanced as the query interface for those systems too, and if you look at the SQL:2011 standard, you'll see that it included methods for querying things that are distinctly "non-relational" (multivalue fields, etc.). NoSQL databases also more cleanly map to object models, the dominant programming paradigm (although who knows, maybe one day that too shall change). No, I don't have a preference of NoSQL vs relational databases in general. I believe they are complementary and maybe there isn't such a thing as a general purpose database for every use case. I do believe in the old saying, "try to use the right tool for the job". There are cases when a NoSQL database works superbly, and others where a relational database just feels right. For example, storing "objects" quickly works well with a NoSQL database vs. querying for a denormalized data warehouse seems to fit well into a relational database (ironically of course, since they are often denormalized and not third-normal-form 3NF). Anyway, that's my take... but anyone else who has input should feel free to chime in.
  - rnprince 10y ago
    Thank you for this reply!
- sixdimensional 10y ago
  I should also have said... they are all databases in the end. I try not to evaluate them based on the label (NoSQL, often a really bad labeling) and simply based on the problem faced and their features. Otherwise, you get lost in NoSQL vs. NewSQL vs. OldSQL vs. ___SQL.

jacquesm 10y ago

> MUMPS had an early "NoSQL" precursor key-value storage engine (the "M" database), that could be directly accessed as if it were a global variable. Yep. And then there were the clustering primitives allowing you to modify variables on other machines. Which takes 'global state' to a wholly different level. You thought it was problematic that a function could change a global variable as a side effect. Wait until you have to debug that global variable changing out from under your feet by a program running on a machine half the continent away.

rnprince 10y ago

Yeah, MUMPS was pretty prescient in this way. As someone who's experienced the changes first-hand, what do you feel are the most important NoSQL developments since MUMPS? Do you have a preference on NoSQL vs relational databases?

sixdimensional 10y ago
Well, this is my opinion. The latest generation of NoSQL databases really tried to add to the distributed / scalability story of databases, as well as provide simpler "input", "output" and "storage mechanisms". This, often at the cost of a degree of ease of use of query languages to be able to easily analyze data. As NoSQL movement started to come into focus, folks saw that the then dominant traditional relational / ACID model was not scaling to internet scale (too many JOINs, too hard to do ACID at that size or not needed, etc.). In reaction to "internet scale", the search turned to finding new or innovative alternatives to the relational model (which really, just represented what was the state of the art at the time). This is how we got BASE instead of ACID, and went back to key-value.. or document-oriented.. or graph-based... or Hadoop/Map-Reduce, etc. People exploring lots of alternatives. I think people mentally "threw relational databases out" for a while as quickly as they threw out the other alternatives (the precursors to relational databases), when relational databases came along. Many have found it hard to live without relational databases. I think modern NoSQL databases try to maximize on input/output/storage and distribution / MPP of data. By now, they give some more expressiveness for query (like MongoDB, Cassandra, Hive/Impala in the Hadoop world), although SQL still beats them in my opinion for ease of use. SQL also could have advanced as the query interface for those systems too, and if you look at the SQL:2011 standard, you'll see that it included methods for querying things that are distinctly "non-relational" (multivalue fields, etc.). NoSQL databases also more cleanly map to object models, the dominant programming paradigm (although who knows, maybe one day that too shall change). No, I don't have a preference of NoSQL vs relational databases in general. I believe they are complementary and maybe there isn't such a thing as a general purpose database for every use case. I do believe in the old saying, "try to use the right tool for the job". There are cases when a NoSQL database works superbly, and others where a relational database just feels right. For example, storing "objects" quickly works well with a NoSQL database vs. querying for a denormalized data warehouse seems to fit well into a relational database (ironically of course, since they are often denormalized and not third-normal-form 3NF). Anyway, that's my take... but anyone else who has input should feel free to chime in.
- rnprince 10y ago
  Thank you for this reply!
sixdimensional 10y ago
I should also have said... they are all databases in the end. I try not to evaluate them based on the label (NoSQL, often a really bad labeling) and simply based on the problem faced and their features. Otherwise, you get lost in NoSQL vs. NewSQL vs. OldSQL vs. ___SQL.