Have you used Intersystems Caché? What is your experience?

Question

I came across few claims that usage of CacheDB instead of proven RDBMS. But I couldn't understand how it is better than RDBMS? if so, why do they prefixed with Cache?

Is it RDBMS or Caché server? Could you write brief notes about the use-case in your project?

Answer 1

Cache is a unique beast, depending on how you use it then it could be described as a No SQL database, an RDBMS, or an object oriented database. Of course it isn't all things to all people, so knowing in what ways it is each needs some explanation.

It's all built on top of a pre-relational procedural language called MUMPS (terrible marketing name that is terrible for Googling as well, so now they just use Cache which is only terrible for Googling). This language includes operations to persist data as native commands, so the persistence engine can be optimized without affecting application code.

This language has one collection type, a key/value dictionary with 0 or more sorted keys, and one data type, that has operators to do stringy things and others to do numbery things. All keys and values are instances of that data type.

This has been around a LONG time, and applications decades old written on top of this still run.

This language predates the first RDBMS, but later implementers of the language added RDBMS support. Cache compiles SQL (statically or dynamically) into a more modern version of MUMPS, which then drives the storage engine. If this sounds weird it isn't really - every RDBMS compiles or interprets SQL into directions for it's storage engine.

Cache has evolved into an object oriented language (like many other languages have done over time), which means there are now 2 data-types, the original one plus the object type. Objects can't be stored as keys or values on disk directly, but can inherit or implement persistence methods.

So people using Cache might use object oriented code, SQL, or procedural code, or combine them as they like.

What are the advantages and disadvantages?

For people running legacy MUMPS applications, they pretty much have no choice, so I'll focus on everybody else.

A big disadvantage is that is has a small market share (compared to other RDBMSs, though it could be compared to other products instead) and is priced in the same ballpark as a commercial RDBMS (though it's probably a lot easier to work out an individual deal for some particular peculiar use of it), so there needs to be some sort of compelling reason to buy it.

Also, the small market share means a smaller market for developers. Plus, the different ways it can be used means not all Cache developers are suited for all projects - someone maintaining a legacy (from before structured programming caught on) application for the last 20 years might not be very good at using Cache for object oriented web applications.

Another problem is that there are pretty much no code libraries outside of what Intersystems (the vendor) supplies, and those can't possibly compete with something like .NET or Java in size.

A big advantage is that Cache Object Script (modern MUMPS language) is a lot more language than you usually get inside a database. This is more of an advantage the more business logic you have in the database.

Actually, IMHO most of the advantages of Cache come if you use it for your business logic. Combining your database and business logic is much simpler, easier to get high performance, and doesn't particularly lead to long term maintenance problems when the environment supports it this much.

The downside of combining database and business logic in Cache is that porting either will be pretty difficult, and usually your business logic is written in a free language and you don't need a license of any kind to run it. Here you are pretty much in the same boat as if your business logic is in TSQL, except it's even harder to port.

If you are O.K. with that, though, many things are lovely. No ORM - commercial or hand-coded. The SQL is compiled into code that you can look at (it's generated so it's optimized for speed over readability and the variable names can be things like 'T32', but it's still readable if you have to), even step through or breakpoint. The cost of writing SQL cursors is very low. You can actually write object oriented code. It's interpreted, so it's easier to develop quickly. If you want speed you can turn off transactions and go No SQL.

I've also found it very easy to administer. In most of my experience with it there is no such thing as a DBA - you just don't need one.

Answer 2

Intersystem's Cache can be defined as Object Oriented Database.

The way I think of it is that it is regular RDBMS database with Object Oriented scripting engine. Oracle has stored procs,Cache has Object script.

We are migrating to Intersystems Cache to take advantage of their BI & reporting tools. I still haven't run across a situation that cannot be solved with stored procedure of MySQL or Oracle yet. I prefer to write everything in SQL procedures to avoid any future migration headaches.

People with strong object oriented background might prefer using ObjectScript.

Just in case you haven't seen it, here is their documentation

Answer 3

It is not RDBMS by design. It is object database. you can use sql interface, and see data like coming from traditional RDBMS.

I was trying it few years ago, just for hobby project, mostly learning.

One notable thing is that before 'all that cloud stuff' they already had system, where you can store data via one node, and it will replicate it for several other nodes. So if you need scaling it can be done. It was cca 10 years ago when replicating data among databases was done by in house tools, afaik. They state there is system with 50k plus people working online with one base. Replication can be done in several ways.

The data are stored in trees, they call it globals. And everything you store is tree. They have object access, actually object in database are objects in your language(Objectscript, I think they had support for java). There is real inheritance in data(globals, call it table would not be correct). So there is no need for hibernate/orm/jpa/... stuff.

They language is hmm, though. If you like Perl one liners, you are fine. Otherwise it is chalenging.