Multi-tenant Support

In this Lesson

You will learn about Soiree’s support for multi-tenant solutions.

Concepts

Multi-tenancy is a design in which a single instance of a solution is used to serve multiple customers. Each customer is called a tenant.

There are three general approaches to managing data for multiple tenants. Each option is described in the sections that follow.

Separate Databases

Features of this approach

  • You run a separate database for each customer
  • You run a separate Soiree server for each customer
  • Provides the maximum isolation among customers
  • Requires environmental changes to host a new customer



Shared Database, Separate Schemas

Features of this approach

  • You run a single database for all customers
  • You create a separate set of tables for each customer
  • You run a separate Soiree server for each customer
  • Requires environmental changes to host a new customer



Shared Database, Shared Schemas

Features of this approach

  • You run a single database for all customers
  • You run a single Soiree server for all customers
  • Requires a tenant identifier column be added to all tables and indexes
  • No environmental changes are needed to host a new customer



Selecting an Option

Each option has benefits and tradeoffs that make it an appropriate model to follow in some cases and not in others. There are a variety of business and technical considerations that should be considered.

  • The number of prospective tenants needs to be considered. Are you building a solution for hundreds of tenants? Thousands? Tens of thousands? The larger you expect your tenant base to be, the more likely you will want to consider a more shared approach.
  • How much storage space do you expect the average tenant to require? If you expect some or all tenants to store extremely large amounts of data then a separate database approach may be best.
  • How many people will be using the system? You need to ensure your environment can provide adequate responsiveness for all customers.
  • Will you offer any per-tenant value-added services, such as the ability to perform backup and restore capability at the tenant level? If so, a separate database approach may be your friend.
  • Determine if your customer is subject to regulatory law that can affect their security and record storage needs.

These options are not mutually exclusive. For example, you may use a shared model for most of your customers and use a separate environment for your larger customers.

What Soiree Provides

All three models are supported by Soiree, however, special support is added for the shared database, shared schema approach.

Soiree eliminates much of cost associated with supporting a shared database, shared schema approach. In most environments there is additional effort to build the software in a way that ensures each customer’s information is viewable by them and no one else. Soiree provides a framework that lowers the development cost to near zero.

Tip
Consider designing your solution for shared database, shared schema. This will provide you the most flexibility in your deployment options. A solution designed for shared database, shared schema can always be deployed using any of the three models.

Designing for shared database, shared schema

We will now discuss how to design a Soiree solution for multi-tenancy.

Soiree provides a SoireeTenant table which contains one row for each customer if you are supporting multiple customers from a single environment.

  • If you intend to support only one customer then leave this table empty, in which case, the tenant ID used in all tables will be defaulted by Soiree to zero (0).
  • If you intend to support multiple customers then this table will contain one row for each customer that is using the system. The tenant id assigned to each customer should be a non-zero value.

Your solution’s needs to be designed as follows

  • Add a tenant column to each table.
    • The tenant column must be an integer
    • The column name used for the tenant ID should be the same in all tables.
      [ we have already done this for you in the lesson’s demo database ]
  • Add the tenant column as the first value on all database indexes.
    [ we have already done this for you in the lesson’s demo database ]
  • The sign-on process used by your customer would need to offer the ability for each person to enter their customer ID [ tenant id ] along with their user name and password.
  • All queries should use the customer’s tenant id to qualify the rows that are accessed in the database.
    • All the queries created for you by Soiree can do this automatically. [ more on this in a future lesson ]
    • You must remember to include the tenant id as a qualifier in all queries that you write manually.

Configuring the Soiree workbench for multi-tenancy

If your solution is designed for multi-tenancy then you should tell Soiree the name of the column that contains the tenant id. Soiree uses this information as follows

  • Soiree will be able to recognize which tables are designed for multiple tenants.
  • Soiree will generate queries that qualify rows using the customer’s tenant id. [ yes, Soiree can write your queries for you! ]
  • Soiree will provide the proper tenant id to all queries.

A column named tenant_id had been added to all tables in the demo database.

You will now tell Soiree the column name that is used to store the tenant id.

  1. Open Eclipse Preferences
    Eclipse … Preferences (OS X) or Window … Preferences (Windows)
  2. Expand the Soiree section and select Datasource
  3. Enter the tenant column name as shown here and then press OK



That’s all for this lesson.