Order is a necessity for everyone, but not everyone understands it in the same way
(Fausto Cercignani)

Disclaimer: This article uses Russian language and Cyrillic alphabet as examples, but is relevant for anyone who uses Caché in a non-English locale.
Please note that this article refers mostly to NLS collations, which are different than SQL collations. SQL collations (such as SQLUPPER, SQLSTRING, EXACT which means no collation, TRUNCATE, etc.) are actual functions that are explicitly applied to some values, and whose results are sometimes explicitly stored in the global subscripts. When stored in subscripts, these values would naturally follow the NLS collation in effect (“SQL and NLS Collations”).

Globals, these magic swords for storing data, have been around for a while, but not many people can use them efficiently or know about this super-weapon altogether.

If you use globals for tasks where they truly shine, the results may be amazing, either in terms of increased performance or dramatic simplification of the overall solution (1, 2).

Globals offer a special way of storing and processing data, which is completely different from SQL tables. They were first introduced in 1966 in the M(UMPS) programming language, which was initially used in medical databases. It is still used in the same way, but has also been adopted by some other industries where reliability and high performance are top priorities: finance, trading, etc.

Later M(UMPS) evolved into Caché ObjectScript (COS). COS was developed by InterSystems as a superset of M. The original language is still accepted by developers' community and alive in a few implementations. There are several signs of activity around the web: MUMPS Google group, Mumps User's group), effective ISO Standard, etc.

Modern global based DBMS supports transactions, journaling, replication, partitioning. It means that they can be used for building modern, reliable and fast distributed systems.

Globals do not restrict you to the boundaries of the relational model. They give you the freedom of creating data structures optimized for particular tasks. For many applications reasonable use of globals can be a real silver bullet offering speeds that developers of conventional relational applications can only dream of.

Globals as a method of storing data can be used in many modern programming languages, both high- and low-level. Therefore, this article will focus specifically on globals and not the language they once came from.

The Art of Mapping Globals to Classes (2 of 3)

If you are looking to breathe new life into an old MUMPS application follow these steps to map your globals to classes and expose all that beautiful data to Objects and SQL.

This example is going to cram in 4 or 5 different things beyond what was covered in Part 1

The Art of Mapping Globals to Classes (3 of 3)

If you are looking to breathe new life into an old MUMPS application follow these steps to map your globals to classes and expose all that beautiful data to Objects and SQL.

If the above does not sound familiar to you please start at the beginning with the following:

The Art of Mapping Globals 1

This post is the direct result of working with an InterSystems customer who came to me with the following problem:

SELECT COUNT(*) FROM MyCustomTable

Takes 0.005 seconds, total 2300 rows. However:

In the previous parts (1, 2) we talked about globals as trees. In this article, we will look at them as sparse arrays.

A sparse array - is a type of array where most values assume an identical value.

In practice, you will often see sparse arrays so huge that there is no point in occupying memory with identical elements. Therefore, it makes sense to organize sparse arrays in such a way that memory is not wasted on storing duplicate values.

In some programming languages, sparse arrays are part of the language - for example, in J, MATLAB. In other languages, there are special libraries that let you use them. For C++, those would be Eigen and the like.

Globals are good candidates for implementing sparse arrays for the following reasons:

Hi folks,
It's time now for a Micro Service Demo with a total fresh IRIS Image and an image that you both PULL with
docker and run with only 4 lines of docker commands.
June 1st, 2020 - rcc

There is now a compact All-in-1 version available that combines all parts in a single container image.
For details see: IRIS-NativeAPI-Nodejs-compact
May 24, 2020 - rcc

I have added a simplified installation using Docker, see context
May 25, 2020 - rcc

There are enhanced scripts suitable & tested for Linux & Windows available here
https://github.com/rcemper/WSockClientMicroSV/blob/master/READMEwindows.MD
May 26, 2020 - rcc

This demo is a redesign of the WebSocket Client based on Node.js existing already for Caché. The major changes:

• use of the new IRIS Native API for Node.js especially Working with Global Arrays
• change from a directly triggered client to a server design
• put the result into a separate docker image as an example for a MicroService / MicroServer
• add a simple interface in IRIS to control the MicroService execution.

NewBie's Corner Session 27 Traversing A Global with $Order Part 1

Welcome to NewBie's Corner, a weekly or biweekly post covering basic Caché Material.

Traversing A Global

Perhaps the most difficult concept in Caché/MUMPS is its Global Structure. This session and several that follow it deals with the Global Structure. However, just presenting the material will not guarantee your understanding of it. You must experiment with the data and concepts that are presented.

InterSystems IRIS supports a unique data structure, called globals, for information storage. Essentially, globals are persistent arrays with multi-level indices, having several extra capabilities—transactions, quick traversal of tree structures, and a programming language known as ObjectScript.

I'd note that for the remainder of the article, or at least the code samples, we'll assume you have familiarised yourself with the basics of globals:

Standard error logs in IRIS / Caché / Ensemble are written global ^ERRORS.
As this piece dates back some decades back to previous millennium its structure
is far from the typical SQL storage structures.

We're developing Ensemble PoC and one day our frontend developer (who doesn't have Ensemble production running) said that Populate just doesn't cut it and he needs to see the real data. He needed only one object, but the problem was - it's a big object. Still, I checked ids of everything related and wrote this command (parts omitted, but you get the idea):

In the prior part of this series we have provided introduction to Google MapReduce approach, but still not covered their possible ObjectScript implementation. Which we will start to explain today.

A More Industrial-Looking Global Storage Scheme

In the first article in this series, we looked at the entity–attribute–value (EAV) model in relational databases, and took a look at the pros and cons of storing those entities, attributes and values in tables. We learned that, despite the benefits of this approach in terms of flexibility, there are some real disadvantages, in particular a basic mismatch between the logical structure of the data and its physical storage, which causes various difficulties.

For some years I missed being able to offer, to everybody interested in ObjectScript, a tutorial more or less complete, to start with ObjectScript. Something that could help more and make things easier to those new developers that come to our technology... something intermediate, halfway between the common "Hello World!", that doesn't really get you further, and the "Advanced Training", that is unaffordable because of lack of time,etc.

If there were something truly helpful not only as an introduction to the ecosystem, but as a starting point, as a boost, to really start to walk into ObjectScript and move forward by yourself... wouldn't that be awesome?