Mapping Multi Tenant Database

Question

Well we are developing a Multi Tenant Application with Separate Databases. All the schema have the same structure for the N separate databases. We are using MySql with aspx to build a web application. Now there will be a situation when there may be same users who are on N separate databases. We need a approach to link up those databases where the user have his/her datas and show it on a dropdownlist. After linking the database when the user login he/she will able to see all the available database in the dropdownlist where his/her data reside. When the user change the dropdownlist values he/she should be able to change the database instantly and view his/her datas form the linked databases. We have built the Multi Tenant Application and every thing is going fine. The problem is that how to map all those database from a master database for the particular user. Every user has a separate Unique ID in the separate database. So user don't have anything common in the Multi Tenant Database other than the data structure. We tried storing all users Unique ID in the master database and linking it with the other Unique ID where the user reside but the solution is not giving fruitful results. Any other alternative is most welcome.

Answer 1

The method I went with for multi-tenant mysql is:

• main database with all of the data all tenants, but every table has a tenantID column which separates out the data by tenant
• create multiple databases for each tenant, but that database is filled with mysql views that reference back to the main database. For example:

.

 # ie. main database has tables: users, and invoices
 # if you have a new tenant named "acme", then:
 create database acme;
 create view acme.users as select * from maindb.users where entityID=2;
 create view acme.invoices as select * from maindb.invoices where entityID=2;

In my situation, this allowed me not have to change any of my previous queries (which were built before I knew I was going to use multi-tenant). All I had to do was select the proper database, and all the data was automatically separate.

But keeping the actual data all in the same database, this simplified maintenance.