Re: Mumps: the IT world's best kept secret?

On Sep 19, 4:44 pm, "Herman Slagman" <herman_slagman@placid-dash-sky-
dot-org> wrote:
Rob,

"Rob Tweed" <rtw...@xxxxxxxxxxxx> schreef in berichtnews:luv4d45sakdoc1j08b0mhvmleoalllr5vo@xxxxxxxxxx

Well of course, that's Java culture influencing his question.  I would
ask "if all I want is to persist a bunch of name/value pairs, why
would I want anything other than the simplicity of a schemaless,
hierarchical database?"

Storing simple name/value pairs is hardly a real-life requirement.
If you go any further than that you'd need a schema of some sort.
If you decide to make the first level subscript of a global the 'primary
key' then you have a schema.
No matter if that is enforced by the database software or by convention in
your project.
If you go for 'raw' globals, you always end up writing your own database
driver that enforces your 'schema'.
If you want SQL-like queries, you have to write your own query 'compiler'..

The Internet has changed the problem. SQL is no longer any kind of
requirement. Most large scale Internet applications (think Flickr,
eBay, Amazon) all provide external access to their data via some kind
of api. Generally they do not use SQL as its not an appropriate or
good solution.


If you decide that piece 23 of the 'record' is a pointer to another global,
then you have to write code that supports that.
Seen it, been there, done that.
If you want to solve a business problem you don't want to write code that
handles all that standard stuff.


The Internet is big. Successful applications need to be able to scale
massively. Many organisations have had to build home grown solutions
because the traditional SQL based solutions just don't cut it. Google
[1], is the most obvious and well known example, but they are not
alone. There are projects such as Drizzle [2] which are trying to
solve the problem from the other end, by cutting the fat out of SQL.


The reasons for Mumps databases to exist, are exactly what you pointed out
in your (excellent) blogg: very complex, high volume, high-performance
database transactions.

High volume, high performance (and sometimes complex) databases are
exactly the issues that every prospective Internet startup has to be
prepared for. Should they be successful, they don't want to fail the
way that Twitter [3] almost did.


All the healthcare systems you mentioned have complex schemas in them,
probably proprietary, not open-source and not compatible with anything else.

VistA?


Google, Amazon and others don't use Mumps databases, yet everybody would
agree that they can serve high volumes of users with excellent performance.

Yes, they can serve high volumes of users with excellent performance,
but they only managed to do this by building their own home grown
solutions. None of the incumbent RDBMS solutions could cut it.
Amazon's SimpleDB virtually reinvented the Mumps database.

But it's all (relatively) simple *data*, as for the bulk of the mainstream
web-sites, no need to use an awkward language with an unknown database.

Intuitively you would expect RDBMSs with strong and rich schemas would
excel when it comes to complex databases. And yet we find that this
is exactly the situations where Mumps databases, with non-rigid
schemas and weak data-typing, tend to really win. Is SQL a help or a
hindrance as complexity increases?


Mumps will always be a niche (embedded) database product, capable of amazing
things but only in very specialized circumstances.
InterSystems understood that and build Cache and Ensemble on top of that
engine, providing us with the ease of Object Schemas and Business Processes
but still providing the raw power of globals when needed.
In all my Cache/Ensemble experience we'd only have to resort to globals once
in a very complex and high-performance situation.

Can you describe the problem you solved? I'd be interested in
understanding the point at which the benefits of globals start to kick
in?

George

[1] http://www.slideshare.net/george.james/googles-bigtable
[2] http://www.builderau.com.au/news/soa/Drizzle-MySQL-slims-down-on-Aker-s-diet/0,339028227,339290807,00.htm
[3] http://www.codinghorror.com/blog/archives/000838.html


Herman

---

Herman Slagman
Placid Sky Consulting
Software Architect of LSP (Dutch National Health Gateway) for CSC Computer
Sciences B.V.

.

Relevant Pages

  • Re: Logins, Users, Roles, Schemas
    ... How do you delete these from a database? ... the logins from the database? ... Passwords Between SQL Servers ... Thus, I believe making Users, Roles, Schemas ...
    (microsoft.public.sqlserver.security)
  • Re: Different databases or schemas?
    ... SQL 2000 and prior do not use schemas in the proper ANSI way. ... If you put the tables in a single database, remember that a database is a ... > single database but with different schemas? ...
    (microsoft.public.sqlserver.server)
  • Re: Mumps: the IT worlds best kept secret?
    ... thinking that's going on with respect to SQL versus REST and JSON as ... hierarchical database?" ... The reasons for Mumps databases to exist, are exactly what you pointed out ... Intuitively you would expect RDBMSs with strong and rich schemas would ...
    (comp.lang.mumps)
  • Re: UDM and Star Schema
    ... and more complicated schemas. ... you create a cube. ... SSAS 2005 is able to create the tables for you, ... proactive caching can detect changes in the source database and then update ...
    (microsoft.public.sqlserver.datawarehouse)
  • Abnormally large merge replication tables
    ... free space is around 10 mb for each database. ... I am running SQL Server 2000 w/SP3a on my publisher/distribution server. ... The MSDE machines move in and out of replication (they are on ... windiff between the schemas created by Enterprise Manager. ...
    (microsoft.public.sqlserver.replication)