2 biggest advantages and disadvantages of a Mumps database

[Matt King]

I'm preparing to instruct a class of Clinical Informatists and as part of the introduction I found myself wanting to say, "The 2 biggest advantages that Mumps has over a relational database is 1) scalability. It can handle very large amounts of information much faster than a relational database and 2) One can add additional structure (nodes) to the database more easily than one can modify the tables in a relational database, once the database contains data."

"The two biggest disadvantages are 1) The data structures and the data are mixed, making it difficult to produce updated versions from a production database that is free of actual patient data and 2) it's hard to find competent programmers/administrators to work on the database."

What are your thoughts on the two biggest advantages and disadvantages of Mumps?

Thanks

Matt

[rtweed]

 Advantage: database.  See:

http://robtweed.wordpress.com/2012/10/21/mumps-the-universal-nosql-database/

Disadvantage: the language.  See:

http://robtweed.wordpress.com/2013/01/22/can-a-phoenix-rise-from-the-ashes-of-mumps/

In summary:

http://robtweed.wordpress.com/2013/05/24/making-mumps-acceptable-to-the-mainstream/

 

[Sam Habiel]

Matt,

On a. #1, relational databases are as or more scalable than M databases.

On b. #1, on the mixing of data structures (like ^DIC) with data (like
^DIC(4.2)), this is A VISTA PROBLEM, and has nothing to do with Mumps.
It used to make sense back in the days when you had one Manager.
machine and multiple other machines running each package. Today it
doesn't make sense.

On b. #2, finding sys admins and programmers has always been an issue
because M was never a common language in the outside world. But again,
there's the part of picking on Mumps; most Computer Science students
are not exposed to the languages they will use in their work until
they do work on it: and a competent sys admin for any database can
manage Mumps databases. It's not really that different. What's really
missing is educational material on Mumps and that is something we are
trying to remedy. But I do have to admit that persuading anybody
(including me) to program in uppercase is rather difficult.

Sam

> --
> --
> http://groups.google.com/group/Hardhats
> To unsubscribe, send email to Hardhats+u...@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Hardhats" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to hardhats+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Ben Irwin]

As far as I know the upper case requirement isn't a MUMPS requirement.  Both Cache and GTM can use mixed case.  See the following for a more readable code example.  Note that is does include extended reference in GTM (It can be done).

 Set MenuName=""

 For  Set MenuName=$Order(^|ov|DIC(19,"B",MenuName)) Quit:MenuName=""  Do

 . Set IEN=$Order(^|ov|DIC(19,"B",MenuName,0))

 . Set Menu(0)=$Get(^|ov|DIC(19,IEN,0))

 . Set Menu(15)=$Get(^|ov|DIC(19,IEN,15))

 . Set Menu(20)=$Get(^|ov|DIC(19,IEN,20))

 . Set Menu(22)=$Get(^|ov|DIC(19,IEN,22))

 . Set Menu(25)=$Get(^|ov|DIC(19,IEN,25))

 . Set Menu(26)=$Get(^|ov|DIC(19,IEN,26))

 . Set MenuDesc=$Piece(Menu(0),"^",2)

 . Set ExitAction=Menu(15)

 . Set EntryAction=Menu(20)

 . Set XquitExecutable=Menu(22)

 . Set MenuRoutine=Menu(25)

 . Set MenuHeader=Menu(26)

 . Write "<tr><td>",MenuName,"</td><td>",MenuDesc,"</td>"

 . Write "<td>"

 . Write:MenuHeader'="" "<b>HEADER:</b> ",MenuHeader,"<br>"

 . Write:EntryAction'="" "<b>ENTRY ACTION:</b> ",EntryAction,"<br>"

 . Write:MenuRoutine'="" "<b>ROUTINE:</b> ",MenuRoutine,"<br>"

 . Write:ExitAction'="" "<b>EXIT ACTION:</b> ",ExitAction,"<br>"

 . Write:XquitExecutable'="" "<b>XQUIT EXECUTABLE:</b> ",XquitExecutable,"<br>"

 . Write "</td></tr>",!

 Write "</table>",!

[Bhaskar, K.S]

On 08/02/2014 06:46 AM, Sam Habiel wrote:
> Matt,
>
> On a. #1, relational databases are as or more scalable than M databases.

[KSB] Based on my experience, I would phrase this as: For some workloads,
relational databases can be as scalable as an M database. I have not
seen any workload in which a relational database outperforms an M database.

> On b. #1, on the mixing of data structures (like ^DIC) with data (like
> ^DIC(4.2)), this is A VISTA PROBLEM, and has nothing to do with Mumps.
> It used to make sense back in the days when you had one Manager.
> machine and multiple other machines running each package. Today it
> doesn't make sense.

[KSB] Agreed

> On b. #2, finding sys admins and programmers has always been an issue
> because M was never a common language in the outside world. But again,
> there's the part of picking on Mumps; most Computer Science students
> are not exposed to the languages they will use in their work until
> they do work on it: and a competent sys admin for any database can
> manage Mumps databases. It's not really that different. What's really
> missing is educational material on Mumps and that is something we are
> trying to remedy. But I do have to admit that persuading anybody
> (including me) to program in uppercase is rather difficult.

[KSB] I can't speak for other MUMPS implementations, but system
administrators is not an issue for GT.M. Usually, regular UNIX/Linux
system administrators just pick it up. That said, there are of course
commands specific to GT.M that the system administrator has to learn.

And yes, you can't just hire MUMPS programmers. But that said, MUMPS
itself is a simple language and easily learned. The problem is hiring
programmers for VistA, not MUMPS. Learning to program - and create good
code - in VistA is not easily learned.

Incidentally, for anyone who wants to see what a contemporary MUMPS
application might look like, look at the FIS InfoHub
(http://www.fisglobal.com/products-technologyplatforms-infohub), which
you can download from
http://sourceforge.net/projects/fis-gtm/files/Applications/InfoHub/

Regards
-- Bhaskar

>
> Sam
>
> On Fri, Aug 1, 2014 at 1:18 PM, rtweed <rob....@gmail.com> wrote:
>> Advantage: database. See:
>>

>> https://urldefense.proofpoint.com/v1/url?u=http://robtweed.wordpress.com/2012/10/21/mumps-the-universal-nosql-database/&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=16Sk%2Fhpom4LByjQO2%2ByvunaX9V2kSBKBPgo7It2nIUg%3D%0A&m=NFCEu8iKeoI5BfCzxWJbGchzM%2Fqqg2CRvm%2F56kbSiUw%3D%0A&s=28797e137db666ab1ee905006af9457e81f4d9deb4fa427c8459f857f6ca6fbc
>>
>> Disadvantage: the language. See:
>>
>> https://urldefense.proofpoint.com/v1/url?u=http://robtweed.wordpress.com/2013/01/22/can-a-phoenix-rise-from-the-ashes-of-mumps/&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=16Sk%2Fhpom4LByjQO2%2ByvunaX9V2kSBKBPgo7It2nIUg%3D%0A&m=NFCEu8iKeoI5BfCzxWJbGchzM%2Fqqg2CRvm%2F56kbSiUw%3D%0A&s=0126a4d7ef3a2f5011a3c87d149a7de292f617577f7073adf89b7589dd4d6a64
>>
>> In summary:
>>
>> https://urldefense.proofpoint.com/v1/url?u=http://robtweed.wordpress.com/2013/05/24/making-mumps-acceptable-to-the-mainstream/&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=16Sk%2Fhpom4LByjQO2%2ByvunaX9V2kSBKBPgo7It2nIUg%3D%0A&m=NFCEu8iKeoI5BfCzxWJbGchzM%2Fqqg2CRvm%2F56kbSiUw%3D%0A&s=07159152c825f6533d685144edbb453a2aca11dc607347d72cfc6c5c06f80131
>>
>>
>> --
>> --
>> https://urldefense.proofpoint.com/v1/url?u=http://groups.google.com/group/Hardhats&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=16Sk%2Fhpom4LByjQO2%2ByvunaX9V2kSBKBPgo7It2nIUg%3D%0A&m=NFCEu8iKeoI5BfCzxWJbGchzM%2Fqqg2CRvm%2F56kbSiUw%3D%0A&s=f0edfc5ff82a656a56eb19debaeda4297feafc6796dc04ae12363a87256e64c9

>> To unsubscribe, send email to Hardhats+u...@googlegroups.com
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Hardhats" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to hardhats+u...@googlegroups.com.

>> For more options, visit https://urldefense.proofpoint.com/v1/url?u=https://groups.google.com/d/optout&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=16Sk%2Fhpom4LByjQO2%2ByvunaX9V2kSBKBPgo7It2nIUg%3D%0A&m=NFCEu8iKeoI5BfCzxWJbGchzM%2Fqqg2CRvm%2F56kbSiUw%3D%0A&s=dd39ec8f18f22c7b038e27d22895b03c6f30a0b4185d1c81500add0ecfa41622.

--
GT.M - Rock solid. Lightning fast. Secure. No compromises.

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.

[rtweed]

On b. #2, finding sys admins and programmers has always been an issue
because M was never a common language in the outside world. But again,
there's the part of picking on Mumps; most Computer Science students
are not exposed to the languages they will use in their work until
they do work on it: and a competent sys admin for any database can
manage Mumps databases. It's not really that different. What's really
missing is educational material on Mumps and that is something we are
trying to remedy. 

Oh that life were that simple - here's the biggest drawback of the Mumps language, no matter what arguments you make for it - it's the existence of this one article:

http://thedailywtf.com/Articles/A_Case_of_the_MUMPS.aspx

Unless you can persuade Google and others to conveniently stop bringing this up every time someone who wants to find out about Mumps, it will act as poison forever.

It doesn't matter whether you agree with the arguments that are made so vociferously in these threads or not - the damage is done and continues to be done.  I have seen it happen every time I or someone else mentions Mumps in a forum: before you know it they've come back with some sarcastic remark based on their impression having read this article.  Once someone has read this posting, no amount of arguments that you try to make about the benefits of the Mumps language will be able to convince them that it's something other than a language to be avoided at all costs.

The solution, however, is surprisingly simple - stop referring to Mumps as first and foremost a language, and instead refer to it as a NoSQL database that happens to have an integrated language....and if you don't like that language, for whatever reason, you can use something else.  I have proven this to work on a number of occasions, even turning one hard-line Mumps hater into something of an evangelist for the database!

By the way, in case you're interested, it turns out that the main perpetrators of the Mumps language hate are ex-Epic developers

Rob

[Andy Bruce]

I happened to run across this paper out of the Intersystems Camp
http://www.intersystems.com/assets/baroudi_bloor.pdf
it relates to #1...in a "total cost of programming" kind of way.
I'm genuinely curious what the group thinks of it...it is 10 years
old...what has changed? Or is it simply hot air? ...and why, speciifically?
Andy

[Matt King]

Thanks, all. If you were listing advantages and disadvantages what would you say? (Understanding that Rob has already answered this.)

[Roy]

Thank you Rob, your vision has come to fruition, and while there will always be naysayers in the MUMPS community, your product (free, thank you very much) will bring back the interest MUMPS lost over the years, except for the few of us who remain loyal to it.  I have been having a lot of fun with ewd.js and see it as the new interface tool to the M backend, while still allowing us old MUMPSters to develop in our language, while allowing us to embrace the newest technologies in development.

 

I expect so see ewd.js/node.js/js in the mainstream of Healthcare IT in the very near future, and quite frankly I am looking forward to it.  This has been a vision of mine and others within the VA for quite some years, but our ideas always fell on deaf ears.

 

Cheers,

 

Roy

--

[Sidney Seo]

That is right, Roy - I am glad you've had an equally enjoyable experience with EWD.js. 

Please contact me offline if ever you need more support demonstrating its capabilities to the budget makers, I am available 24/7/365 and live for this stuff.

My abstract on 9/3 at the OSEHRA Summit will feature:

• CPRS Evolution
• Fileman GUI
• Reminder Dialog Editor GUI
• Template Editor GUI

Demo videos for CPRS Evolution/Reminder Dialog Editor GUI are targeted for 8/22.  Stay tuned!

Oh yea... thanks again Rob!

[Steven McPhelan]

In addition to changing one's approach such as referring to M as a NoSQL database, one could take the approach of Interystems in that its database technology has an associated scripting module (called M).  Those outside of M are very familiar with the concept of a high-level, enterprise-level product having its own "scripting tools" for managing the database technology.

Steve

The urge to save humanity is almost always a false front for the urge to rule - HL Mencken