Multitenant SQL Server Architecture
Posted by Joe on May 6, 2009
We have a very large database where I work that is architected as a multitenant database. This is great since all we have to do is add a new customer record, and the rest takes care of itself. Because of the proprietary nature of our platform, I can’t put the table schemas up here for you to look at. However, I am looking for advice or techniques you may have used to solve a particular problem.
When customers import their data, imports go fairly slow. We give customers standard fields to import data into, but then they also have the option of importing custom fields. The table that holds custom fields allows one record per customer/user/field. Each record is tied to the user, and the user data is stored in another table. If a customer has 10 custom fields defined and they upload 50,000 users with all 10 field values, this is a total of 500,000 custom data records. The import process has to first see if the custom data exists. If so, it updates that record. If not, it inserts a new record. As you can imagine with this process, the more custom fields a customer has, the slower the import process becomes. Each custom field has to be tied to the user before it gets updated or inserted. The user may or may not exist, so we have to first insert or update the user, get the user id, and use that for each custom data record. That means no bulk loading because we first need the user id. Think of it as a master-detail relationship. The table that holds users is the master. The table that holds custom data is the detail.
I’m curious to know what you’ve done, or would try to do with a scenario like this to make it super fast.
