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.