schemaless and hierarchical databases
Rob Tweed
about MUMPS, hierarchical and schemaless databases:
---
Rob Tweed
Company: M/Gateway Developments Ltd
Registered in England: No 3220901
Registered Office: 58 Francis Road,Ashford, Kent TN23 7UR
Web-site: http://www.mgateway.com
Don't miss this year's Out of the Slipstream Conference
Thursday 3rd July, Bletchley Park
http://www.outoftheslipstream.com
Rob Tweed
http://www.slideshare.net/george.james/mumps-the-internet-scale-database-presentation/
On Sat, 16 Aug 2008 11:31:46 +0100, Rob Tweed <rtw...@mgateway.com>
wrote:
Rob Tweed
http://www.outoftheslipstream.com/node/125
The absence of any discussion or follow-up on this newsgroup thread is
depressingly telling....
On Sat, 16 Aug 2008 11:31:46 +0100, Rob Tweed <rtw...@mgateway.com>
wrote:
>Some of you may be interested in checking out the following posting
Kevin O'Kane
of which is:
We use Mumps in our Information Storage and Retrieval
course at the University of Northern Iowa. It is an ideal
platform in which to explore large scale applications
for classifying and categorizing textual information.
We also use in it a number of bioinformatics projects
where, likewise, the global array data base is well
suited to the problem at hand.
In our version of Mumps, which is similar but not
fully identical to the old standard, we've added
many functions such as Smith-Waterman sequence
matching, Perl pattern matching, document vector
correlation functions (Cosine, Jaccard, et al.) as well
as Boyer-Moore-Gosper and n-gram based searching.
We see our system as a platform to explore new applications
and ideas. Our version is free, written in C++, runs
on Linux, Cygwin and Windows (some restrictions
apply) and is GPL licensed. See:
The above linked page has links to the Mumps download,
a C++ class library to enable Mumps-like file and
string access from C++ programs and a link to our
online text book in information retrieval, written
in Mumps.
Our built-in global array data base has a theoretical
upper limit of 256 terabytes and we've recently installed
a feature that permits storage of global arrays in the
the PostgreSql relational database system as well
as queries of in same.
We've also implemented full shell command execution
by means of a "shell" Mumps command. Our system
also supports Mumps scripting for cgi-bin active server
pages and an "html" command that permits Mumps
expressions to be embedded into HTML statements.
We treat Mumps as a scripting language. Our students
find it intriguing for certain applications and when surveyed
by others faculty in other courses, they consistently rank
Mumps as one of their favorites.
An all-purpose programming language Mumps is not.
As a specialized language in the category of PHP,
Perl, et al., I think it has a strong future.
But my personal observation is that Mumps is too closely
linked with the VA system and the VA system is a collection
of examples of how not to program.
As long as code segments like:
WP(DDBFN,DDBRN,DDBFLD,DDBFLG,DDBPMSG,DDBL,DDBC,IOTM,IOBM) N DDBSA
S DDBSA=$$GET^DIQG($G(DDBFN),$G(DDBRN),$G(DDBFLD),"B")
I $G(DIERR) D CLEAN Q
S DDBSA=$P(DDBSA,"$CREF$",2)
I DDBSA']"" D ERR("FILE, RECORD and/or FIELD") Q
I '$D(@DDBSA) D ERR("SOURCE ARRAY") Q
I $G(DDBFLG)["A" D
.N DDBSAN
.S DDBSAN=$$NROOT^DDBRAP($NA(@DDBSA))
.I '$D(@DDBSAN) D WP^DDBRAP($NA(@DDBSA))
.Q:$G(DDBPMSG)]""
.I $D(@DDBSAN@("TITLE")) S DDBPMSG=@DDBSAN@("TITLE") Q
.Q
S DDBPMSG=$S($G(DDBPMSG)]"":DDBPMSG,1:"VA FileMan Browser (wp) DOCUMENT 1")
D CONTNU
D:$G(DDBFLG)'["P" KTMP^DDBRU
Q
is seen as the state of the art, the art won't be admired.
Kevin O'Kane
University of Northern Iowa
Cedar Falls
Rob Tweed
Thanks for your posting! :-)
I agree entirely with your sentiment below. The unfortunate thing is
that there's no need for such obtuse coding these days, but then again
it's only relatively recently that we've had the advantage of long
label and variable names to make it all much more maintainable. Sadly
it's this kind of legacy coding that the detractors of Mumps tend to
see and/or remember, and they're only too ready to tar everyone with
the same brush.
Rob
On Sun, 31 Aug 2008 13:13:21 -0500, Kevin O'Kane <ok...@cs.uni.edu>
wrote:
>But my personal observation is that Mumps is too closely
>linked with the VA system and the VA system is a collection
>of examples of how not to program.
>
>As long as code segments like:
>
>
>WP(DDBFN,DDBRN,DDBFLD,DDBFLG,DDBPMSG,DDBL,DDBC,IOTM,IOBM) N DDBSA
> S DDBSA=$$GET^DIQG($G(DDBFN),$G(DDBRN),$G(DDBFLD),"B")
> I $G(DIERR) D CLEAN Q
> S DDBSA=$P(DDBSA,"$CREF$",2)
> I DDBSA']"" D ERR("FILE, RECORD and/or FIELD") Q
> I '$D(@DDBSA) D ERR("SOURCE ARRAY") Q
> I $G(DDBFLG)["A" D
> .N DDBSAN
> .S DDBSAN=$$NROOT^DDBRAP($NA(@DDBSA))
> .I '$D(@DDBSAN) D WP^DDBRAP($NA(@DDBSA))
> .Q:$G(DDBPMSG)]""
> .I $D(@DDBSAN@("TITLE")) S DDBPMSG=@DDBSAN@("TITLE") Q
> .Q
> S DDBPMSG=$S($G(DDBPMSG)]"":DDBPMSG,1:"VA FileMan Browser (wp) DOCUMENT 1")
> D CONTNU
> D:$G(DDBFLG)'["P" KTMP^DDBRU
> Q
>
>
>is seen as the state of the art, the art won't be admired.
---
Jim
While I am simply an applications programmer, perhaps some of my
experiences can be useful. I have programmed mostly in MUMPS or
similar languages since 1981. I have used it in library information
systems, clinical systems (order entry/radiology/laboratory/pharmacy),
registration systems, inhouse applications (timekeeping systems and
menu systems) and personal projects. Sometimes I have used objects
(the latter 2 inhouse systems using Caché objects), but mostly just
plain MUMPS. However, in all of these systems I never felt hampered
nor did I notice the users being hindered in their workflow. Let me
offer a few examples of just the opposite.
I worked in one non-MUMPS shop where they utilized a roll-your-own
database running in character mode written in FORTRAN under a
proprietary OS and hardware architecture. Although the users loved
the system and it was quite powerful and very fast, management got it
into their heads that they had to move to a GUI/Unix/C++/RDBMS
system. Sad to say that this pioneer in laboratory information
systems took too long to reach the promised land, could no longer sell
their legacy systems (the users all heard about the new product, of
course) and were soon acquired and their lab business languished.
Although this is not a MUMPS story per se, the principles are the
same. Again the users loved the system and it did quite nicely as
is. And if they wanted to enhance it in particular instances, one
company had come up with a PC product which accepted input from their
inquiry system and transformed it into beautiful graphics (this was in
the early 90's). Another company did a similar add-on for their
outbound fax reporting. It was a case of using technology to its best
use.
In another case a company acquired our MUMPS-based company and refused
to continue using our MUMPS-based reporting system. Rather they took
an off the shelf product, which was not designed for the task at hand,
and shoe horned it into doing the job. By the time they got finished,
they had probably 4 times the hardware invested that needed to be
used. Also they were not able to modify reports on the fly, which our
old company could and which it used as a selling point for potential
customers.
Finally I interviewed with a MUMPS-based vendor and they too had
caught the RDBMS/GUI fever. Problem was that their customers liked
the current MUMPS/CHUI (character-based ui) system and they were
having problems selling it. That was probably 10 years ago and today
I use that same MUMPS/CHUI software and it works just fine.
What I have learned from the above is that a relational database is
not necessary for producing good results in the workplace. In fact
sometimes either a home-grown database or MUMPS can run rings around
one in performance at least. I've also learned that a graphical user
interface is not necessarily the only or even the best user
interface. I've worked mostly in laboratory or laboratory information
system settings and there the users need throughput - and in many
cases that translates to something simple to view and fast to input.
MUMPS has excelled in this for years and its built-in database has
enabled it to leverage seemingly low-power systems into something
more.
And now, if a GUI is needed, there is the web or synching up the MUMPS
database with a pretty front end. Seems like a good solution to me
and a simple one to boot.
Steve Graham
===
On Aug 31, 9:05 am, Rob Tweed <rtw...@mgateway.com> wrote:
> Some more thoughts on this at:
>
> http://www.outoftheslipstream.com/node/125
>
> The absence of any discussion or follow-up on this newsgroup thread is
> depressingly telling....
>
> On Sat, 16 Aug 2008 11:31:46 +0100, Rob Tweed <rtw...@mgateway.com>
> wrote:
>
>
>
>
>
> >Some of you may be interested in checking out the following posting
> >about MUMPS, hierarchical and schemaless databases:
>
> >http://groups.google.co.uk/group/enterprise-web-developer-community/b...
>
> >---
>
> >Rob Tweed
> >Company: M/Gateway Developments Ltd
> >Registered in England: No 3220901
> >Registered Office: 58 Francis Road,Ashford, Kent TN23 7UR
>
> >Web-site:http://www.mgateway.com
>
> >Don't miss this year's Out of the Slipstream Conference
> >Thursday 3rd July, Bletchley Park
> >http://www.outoftheslipstream.com
>
> ---
>
> Rob Tweed
> Company: M/Gateway Developments Ltd
> Registered in England: No 3220901
> Registered Office: 58 Francis Road,Ashford, Kent TN23 7UR
>
> Web-site:http://www.mgateway.com- Hide quoted text -
>
> - Show quoted text -