Question

I am designing application for multiple customer usage. I ended up creating single database setup with schema per customer layout which looks something like this:

CREATE TABLE public.companies
(
  id serial NOT NULL,
  name long_name NOT NULL,
  registration_number character(11),
  address character varying(256),
  CONSTRAINT "CompaniesPrimaryKey" PRIMARY KEY (id )
);

CREATE TABLE public.banks(.. );
CREATE TABLE public.calendars(.. );

-- Schema definition - none of the tables have company_id key
-- company_1 schema
CREATE TABLE company_1.employees
(
  id serial NOT NULL,
  first_name character varying(30),
  middle_name character varying(30),
  last_name character varying(50),
  bank_id integer,
  CONSTRAINT employees_pkey PRIMARY KEY (id )
);

CREATE TABLE company_1.contracts
(
  id serial NOT NULL,
  employee_id integer,
  calendar_id integer,
  CONSTRAINT contracts_pkey PRIMARY KEY (id )
)

-- company_2 schema same as schema company_1
-- and so on ...

In every discussion I have some argument about database design somebody says that there is something wrong with it, but nobody can say what, just gut feeling.

Is there anything really wrong with it? What are real caveats of this design?

Answer 1

The problem is that in case of schema changes you have to upgrade all of them so that the applications finds a consistent structure. Your upgrade script must be atomic for all of them.

If the tables are in the same database that shouldn’t be too bad because you can wrap the upgrade script in a transaction.

If you use database-per-customer on the other hand, and the RDBMS does not support multiple databases per transaction, you might upgrade some customers while “crashing” others.

Also, you cannot make one customer read from other customers easily if you want that (for example you might want to give all customers an auto-complete list filled by the data of all customers).