Here is a test for running all those codes. 
It looks like that the 1st solution (with $translate) is the fastest.

Very good article, Laurel.

To me, as one that has many years of experience with software development, it is obvious.

However, I also learned in my career that a good & precise design of your data model, using correct (and compact) storage of values, building the relationships correctly (in case of OO approach), using proper indices & fine tuning queries (in case of SQL approach) can make a huge difference between a "normal" and "high-end" systems.
All those become a major concern when we are talking about a very "high volume" systems that needs to process hundreds of millions of transaction per day.

Going to "compact" data model with a reliable code will save you also a lot in your capacity planning both in a cloud hosting or on premise.

Hello,

Will the "Built-in license for InterSystems SAM Manager" be effected as well ?

the "Expiration Date" is 0 - so i guess it is not, but just want to be sure ...

DB tuning has many aspects:
1. When the DB is a SQL one (persistent classes) than as some said a "tune table might help, but this will help mostly with SQL queries, by optimizing the use of (correct) indices.
There are other SQL tools on the portal (query plan, sql index usage etc.) that might help to see if the indices are correct.

2. Using the correct data types for your data (e.g. using %Date data type to store dates in $horolog format is much more effective than a %String (YYYY-MM-DD) on large scaled databases, especially with indices where cache memory can not hold most of the DB or with systems with huge number of transactions).
BTW, this is true to both persistent classes (that you access qwith SQL) and "raw" globals that you access with COS (or other language).

3. In a large scald DBs if some of your queries are "heavy" - code optimization might also be a consideration (e.g. replacing SQL with COS that does direct $Order on the index globals).

quine ; quine routine is a routine that prints itself content
X "ZL "_$T(+0)_" ZP"
Q

to avoid hardcode the actual routine name, you may do:
X "ZL "_$T(+0)_" ZP"

what is the vet.numConselho for those 2 records ?

consider also that even when you use the DISABLE^%SYS.NOJRN if you are within a transaction globals will be saved (e.g when doing a %Save() on an object).

To prevent this you may use:
$system.OBJ.SetTrandsactionMode(0) - to disable transaction
$system.OBJ.SetTrandsactionMode(1) - to enable transaction (leter)

There is a stand alone studio called "IRIS studio" that can be installed independently (no need for IRIS install).

If you download the latest version it will support "backward" all versions of Cache/IRIS 

There are few considerations here:

1. If you are using a failover (sync) mirror, you will need to that Ens.* data on the backup so a switch can be done seamlessly, and Ensemble production can start from the exact same point when failure occurred.

2. mapping any globals into a non-journal database will still have them on the journal when the process is "in transaction". Ensemble production is writing everything "in-transaction"

3. Mapping Ens.* to another DB is good idea if you have several disks, and you want to improve I/O on your system (specifically within cloud VMs that usually have a bit slower disks than on-premise). Another option is to let the system purge Ensemble data regularly and maybe keep less days of history.

4. Mirror journals are regularly being purged after all sync/a-sync mirror members got them.

In my opinion, it is much better & faster to store binary files out of the database. I have an application with hundreds of thousands of images. To get a faster access on a Windows O/S they are stored in a YYMM folders (to prevent having too many files in 1 folder that might slow the access) while the file path & file name are stored of course inside the database for quick access (using indices). As those images are being read a lot of times, I did not want to "waste" the "cache buffers" on those readings, hence storing them outside the database was the perfect solution.

Using $Extract will be 17 % faster (!)
Set date=20201121090000  
Set newDate=$E(date,1,4)_"-"_$E(date,5,6)_"-"_$E(date,7,8)_" "_$E(date,9,10)_":"_$E(date,11,12)_":"_$E(date,13,14)
 

Thank you Robert,

Excellent article.
In fact we use this approach when we need to gain speed for queries that run on hundreds of millions records indexes and need to check few items only, so we save checking the "base" class by using [ DATA ... ]  

In addition, to gain more speed, which is so essential in huge queries, we use the (good, old) $order on the index global itself to gain more speed. This is much faster than normal SQL. 

Hello,

I recommend either ways:

1. copy the *.DAT file to new server: for this you need to dismount the DB on source before copy (so you have downtime), mount it and do a merge between 2 DB/Namespaces.

2. Do a (hot) backup for the DB that has the table  = NO downtime (!) - then copy the *.BCK file to other server, restore to a NEW DB and merge.
This is slower - but downtime is 0

Analytics (aka DeppSee) build it.

also... great advantage for Intersystems itself (to earn more for license upgrade).