New post
Question
· Aug 23, 2017

What is the benefit to keep separate database for Globals and Routines?

#Databases #Distributed Data Management #Ensemble

While creating namespaces, there is a provision for keeping the data, and code separately in database.

What I am looking for,

What are the benefit we can achieve by doing this?

Is there any documentation of article which might help understanding?


Thanks You!

Discussion (9)1
Log in or sign up to continue
Ben Spead · Aug 23, 2017

There is a huge benefit from two perspectives:

- If you need to refresh data in your Dev or Test environment, you can just grab the globals DB from Live and drop it in and not worry about overwriting any code in Dev or Test

- If you choose to deploy your code via a DB drop, you can drop in a new DB to replace the existing routines DB

NOTE - for either of these to work, you may need to map configuration into the routines DB (so you don't bring back Live config into Dev for instance)

HTH!

Ben

5 0
Dmitry Maslennikov · Aug 23, 2017

This possibility is not alone, it is also possible to have more than one or two databases for one namespace.

There is also mapping, for globals class packages and routines.

One of the reasons to use it is to split different parts of applications. For instance:

  • Let's say, you are a software developing company. Mostly it is enough to deliver to your customer only your compiled code, and it is easy to do it with CACHE.DAT, while a customer has database only with data. So, an update should be quite easy in this case, replace cache.dat, call some update code if needed.
  • Or, you have one application, but should have different data, by some reasons. You can use one database with code, in multiple namespaces. But each namespace will have different databases for Data.

With mapping, you have more flexibilities, like split your code in different databases. If you deliver your code to the customer but gave permission to extend some functionality. In this case, you can put customer's code to another database. Or you can split data to get better performance. If you would have so much count of writing to your database, you can split this data and place this database files to different hardware discs, you may get better writing speed. Or even some part of data in a namespace can be stored on another server and connected through ECP.

So, I can say that even could be more reasons to split data in databases. And always it depends on a project and needs.

You should read this article in the documentation about mapping to get more information about it.

2 0
Andre Cerri · Aug 23, 2017

There is also the added benefit of minimal downtime upgrades in a Mirrored environment. Basically you don't mirror the  code database, and maintain that manually. But this allows you to update the code on the failover member, fail over to it, and then upgrade the code on the old primary. Without this, you cannot update the "single" code/data database on the failover member as it is read-only.

This is a little more complex on Ensemble and Health Connect, but the principle is the same.

1 0
Luca Ravazzolo · Sep 14, 2017

In general, it is a good thing to have these 2 concerns (code vs data) separate. You're de-coupling 2 items (concerns, concepts) that are effectively different. When using technologies like containers & container services this point becomes even more apparent and allow you to be much more flexible and agile in your deployments. Of course, schema migration is still an issue, but the separation still helps. This is one of the reason why orgnaizations can perform multiple deployments per day.

HTH

0 0