Virtual instance of a database schema on DB2

Question

My question is pretty straight forward:

I'm developing a system, which will be installed in several companies. I don't want to use a field in every table to separate data for one company to another, I want to use a more scalable solution.

My idea is to model a single database schema and have an "instance" of it for every company I instance in my system, thus backing-up a single database or base schema and also propagating changes for every schema just by modifying my base schema. In short, there would be only one base or physical schema and many data instances of it, referenced by a unique schema name.

Is this possible? What is this technique called? (I would be using this concept for the first time) How do I implement it on IBM DB2?

Answer 1

If I understand you correctly, I don't think it's possible. I'm pretty sure it's not practical.

Imagine adding a column and an index on that column to your base schema. In one company, where they don't have a lot of data, that change is fairly trivial. But a company that has many millions of rows might find itself suddenly out of disk space.

A DBA might manage that problem by moving an index or table to a different disk or a different filesystem, but that might not be possible if the database were "instanced" off your base schema. (Depends on what you mean by instanced , which has a DB2-specific meaning as well as a more general OOP meaning.)

The term you're looking for, I think , is "multi-tenant". ( Tenant and customer mean just about the same thing here.) SO has a "multi-tenant" tag; I'll add it for you, and you can delete it if it's not appropriate. IBM's developerWorks library has an introductory article on the various multi-tenant architectures .

Multi-tenant architecture ranges from "shared nothing" (each tenant gets their own database) to "shared everything" (all tenants share the tables in a single database, each row has a column that identifies the tenant who "owns" that row).

Between "shared nothing" and "shared everything" is "shared schema" (tenants share a database; each tenant has a private schema).

The most obvious differences are in customization, disaster recovery, and data isolation. These differences also drive the choice of architecture.

"Shared nothing" makes customization easy; changing the database can't affect any other tenants. Disaster recovery is simple, too; you just restore a whole database from backup. Permissions can be applied at the database level for near-perfect isolation.

"Shared everything" makes customization hard; every change affects every tenant to some degree. Disaster recovery is also hard; for a single-company disaster, you have to restore some rows--just the rows that single company "owns"--to every table. Data isolation is harder, too, because every view and query you deploy has to correctly account for the tenant identifier. Forget that just once, and you might be out of business.