Home/ Questions/Q 4607978
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-22T00:46:45+00:00

I know this question has been asked so many times before but I couldn’t

  • 0

I know this question has been asked so many times before but I couldn’t find the exact answer for mine. So please let me ask it here.

We built a CMS to control one site. Now the company is expanding and we have a couple more sites with almost identical core structure. We decided to go with one database for easy maintenance later on.

We have about 10 tables. For example, Pages, News, Settings (different for each site), …

It doesn’t sound like a good idea if we add one App_ID (or Site_ID) column to every each of these tables so we know what records from which particular site we should pull out.

For instance,

PAGES:
PageID   |   Body   |   SiteID
1        | abc      |   1
2        | cde      |   1
3        | aafd     |   2
4        | gsgs     |   2
5        | feg      |   3

I think it is very abundant to add this SiteID Column to every table in this Database.

I looked carefully at the Multi-Tenant Architecture but I don’t know how to apply it to our sites CMS.

What is the best way to handle this situation, please help. Any enlightenment is appreciated.

Simple Code

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    We’ve recently been reviewing various strategies for multi-tenant single database.

    If you don’t want to add a Site identifier to your tables then you could give each tenant their own schema and set of tables. Each tenant could have their own connection string which only provides access to their schema (you would obviously need to switch connection at runtime (easy enough with both EF and NH if you are using these).

    However, the option we opted for was to introduce an additional level into our application such that each component of the application (in your case News, Pages etc.) was represented as a feature in the database.

    Each site then has a collection of feature “instances” and the data stored for each of those features (a blog might have posts, tags, categories) has a reference to the feature instance (not the site).

    This does add additional complexity but we have found it to be extremely flexible and decouples our feature data from the site (make it possible to move feature instances between sites if we wanted to).

    • 0