Mumps: the proto-database (or how to build your own NoSQL database):
I think that one of the problems with Mumps as a database technology, and something that many people don’t like about the Mumps database is that it is a very basic and low-level engine, without any of the frills and value-added things that people expect from a database these days.
Interesting, these guys have been around for decades, yet (almost) nobody is using them as foundation for their own NoSQL store? Maybe here’s why –A Case of the MUMPS:
You may not realize it, but the majority of us developers have been living a sheltered professional life. Sure, we’ve got that living disaster of a C++ application and that ridiculous interface between PHP and COBOL written by the boss, but I can assure you, that all pales in comparison to what many, less fortunate programmers have to work with each day. These programmers remain mostly forgotten, toiling away at a dead-end career maintaining ancient information systems whose ridiculously shoddy architecture is surpassed only by the tools used to create it. Bryan H lived in such a world for over two years. Specifically, he worked at a “MUMPS shop.”
Via myNoSQL.
Comments
4 responses to “Mumps: the NoSQL Proto Database”
As is depressingly common, you’ve read the “Case of Mumps” at face value and decided, as a result, to ignore a unique and powerful database. Think about it for a few minutes: what you’re doing is dismissing a database because of deficiencies in a language – sure, it’s an antiquated language that is obsolete, but you have to realise that it’s a language that is no longer a necessity for use with the Mumps *database* – which is what you’ll discover my articles are all about – the Mumps *database*.
Couple the Mumps database with a modern one (your choice), and you have a (read my lips) *database* that is seriously interesting and worth investigating.
If you’re genuinely interested in databases, stop getting sidetracked by this language red herring. It’s like criticising MySQL because most people used to use PHP with it.
Rob, thx for stopping by. I merely try to show two sides, not dismissing GT.M just because of somebody’s juicy story. Indeed I’m still curious to understand what it provides wrt sharding and parallel processing, because that’s what’s typically missing when you take an existing DBMS to power a new NoSQL DB (like Oracle did with Berkeley DB to create their NoSQL DB, IIRC).
I manage GT.M (http://fis-gtm.com) and I think the term proto-database is about right. GT.M is basically a combination of a highly-scalable data-store, a low-level scripting language which is easily accessed from a variety of other languages (C, C++, node.js, Python, Ruby, Erlang, etc., with Java to come soon), and management utilities. The data-store is natively hierarchical, multi-dimensional associative memory or key-value (pick your paradigm) but lends itself to mapping common NoSQL use cases (see http://www.mgateway.com/docs/universalNoSQL.pdf). GT.M supports ACID transactions, and two types of replication. While GT.M does not inherently support sharded queries, as a proto-database, it would not be hard to write an application that does make sharded queries.
Thx K.S.