Is this multi-tenant database design is good

Question

I am working on a multi-tenant website project. This project will manage the appointments for the tenants. Like a Hair dresser may be a tenant for this project. So hair dresser tenant have staff and Customers associated with it.Each customer will be served by any one staff member.

I have a question about the database design for this type of scenario. In this scenario i have 3 entity namely:

• Tenant
• Staff
• Customer (Customer is the user for the tenant)

First i will tell you about my thought for such database design and then i wants your expert advice.

What i thought is:

For me Tenant , Staff and Customer are all belongs to a same category so i have decided a single table for all of them (Say User) . This table contains a TypeId column which will differentiate between three of them. This table contains a self-referencing relationship for Tenant-Staff and Tenant-Customer which may be 1 to many .

Visual Representation of my thought:

I am not good in database design and i want my database design as good as possible and extendable . So i am here to ask you guys please review my design and tell me the pros and cons of this design for this scenario and please suggest me a better design, if there is any other, for the scenario i mentioned above.

And BTW i am using Entity Framework Code First in my project.

Thanks.

Answer 1

The customers table will hold information specific to customers. In my example data we see that Mary and Greg are customers. Instead of storing first_name, last_name, etc. here I simply store a foreign key to the users table. I do this because we may have a user who is both a Customer AND an Employee (staff) - why would we want to make them create more than one sign on? Obviously there's a lot more you would want to store in this table.

customers
    id              unsigned int(P)
    user_id         unsigned int(F users.id)
    ...

+----+---------+-----+
| id | user_id | ... |
+----+---------+-----+
|  1 |       2 | ... |
|  2 |       3 | ... |
| .. | ....... | ... |
+----+---------+-----+

The same customer can be associated with many different tenants and each tenant can have many different customers, this table ties them together. Each column is a foreign key to it's respective table and together they form the primary key for the table. In my example data we see that Mary is a customer of Barbie's Hair Salon as well as Ken's Gym and Greg is a customer of Ken's Gym .

customers_tenants
    customer_id     unsigned int(F customers.id)--\_(P)
    tenant_id       unsigned int(F tenants.id)----/

+-------------+-----------+
| customer_id | tenant_id |
+-------------+-----------+
|           1 |         1 |
|           2 |         2 |
|           1 |         2 |
| ........... | ......... |
+-------------+-----------+

What you call staff is what I would call employees, these are people who work for a tenant. In my example data we see that Bob and Mary both work for Barbie's Hair Salon and Greg works at Ken's Gym .

employees (staff)
    id              unsigned int(P)
    user_id         unsigned int(F users.id)
    sin             unsigned int // Social Insurance Number
    dob             date // Date of birth
    hired           date
    ...

+----+---------+-----------+------------+------------+-----+
| id | user_id | sin       | dob        | hired      | ... |
+----+---------|-----------+------------+------------+-----+
|  1 |       1 | 123456789 | 1995-01-01 | 2013-12-13 | ... |
|  2 |       2 | 987654321 | 1996-01-01 | 2013-10-30 | ... |
|  3 |       3 | 123459876 | 1994-01-01 | 2013-01-24 | ... |
| .. | ....... | ......... | .......... | .......... | ... |
+----+---------|-----------+------------+------------+-----+

We need a table that ties employees and tenants together. This table is very similar to the customers_tenants table. In my example data we see that Bob works at Ken's Gym and Mary works at both Barbie's Hair Salon and Ken's Gym .

employees_tenants
    employee_id     unsigned int(F employees.id)
    tenant_id       unsigned int(F tenants.id)

+-------------+-----------+
| employee_id | tenant_id |
+-------------+-----------+
|           1 |         2 |
|           2 |         1 |
|           2 |         2 |
| ........... | ......... |
+-------------+-----------+

In the tenants table we store information about each tenant. Obviously you will have much more than just a name.

tenants
    id                  unsigned int(P)(F users.id)
    name                varchar(50)
    ...

+----+---------------------+-----+
| id | name                | ... |
+----+---------------------+-----+
|  1 | Barbie's Hair Salon | ... |
|  2 | Ken's Gym           | ... |
| .. | ................... | ... |
+----+---------------------+-----+

And finally we have a table with user information. Since customers and employees are subsets of users we store all common information such as first_name, last_name, etc. here.

users
    id              unsigned int(P)
    username        varchar(32)
    password        varbinary(255)
    first_name      varchar(30)
    last_name       varchar(30)
    ...

+----+----------+----------+------------+-----------+-----+
| id | username | password | first_name | last_name | ... |
+----+----------+----------+------------+-----------+-----+
|  1 | bob      | ******** | Bob        | Sled      | ... |
|  2 | mary     | ******** | Mary       | Poppins   | ... |
|  3 | greg     | ******** | Greg       | Stamps    | ... |
|  4 | jen      | ******** | Jennifer   | Jones     | ... |
| .. | ........ | ........ | .......... | ......... | ... |
+----+----------+----------+------------+-----------+-----+