这个多租户数据库设计好吗？

Question

我正在做一个多租户网站项目。这个项目将管理租户的预约。就像美发师可能是这个项目的房客一样。因此，美发师租户有员工，与it.Each相关的客户将由任何一名工作人员提供服务。

我有一个关于这类场景的数据库设计的问题。在这个场景中，我有三个实体，即：

• 租户
• 员工
• 客户(客户是租户的用户)

首先，我会告诉你我对这样的数据库设计的想法，然后我想要你的专家建议。

我想的是：

对我来说，租户、Staff和Customer都属于同一个类别，所以我已经为它们(比如用户)决定了一个单一的表。此表包含一个TypeId列，该列将区分其中三个列。此表包含Tenant-Staff和Tenant-Customer的自引用关系，可能是对多个的1。

我的思想的视觉表现：

​

​

我不擅长数据库设计，我希望我的数据库设计尽可能好和可扩展的。所以我想问你们，请回顾一下我的设计，告诉我这个方案的利弊，如果还有其他的，请给我一个更好的设计方案。

在我的项目中，我首先使用的是实体框架代码。

谢谢。

Answer 1

customers表将保存特定于客户的信息。在我的示例数据中，我们看到Mary和Greg是客户。这里不是存储first_name、last_name等，而是将一个外键存储到users表中。我这么做是因为我们可能有一个同时是客户和员工(员工)的用户--我们为什么要让他们创建多个登录呢？显然，你还想把更多的东西放在这张桌子上。

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

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

同一个客户可以与许多不同的租户相关联，每个租户可以有许多不同的客户，这个表将它们联系在一起。每一列都是其各自表的外键，它们一起构成表的主键。在我的示例数据中，我们看到Mary既是Barbie's Hair Salon的客户，也是Ken's Gym的客户，Greg是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 |
| ........... | ......... |
+-------------+-----------+

你所说的员工就是我所说的员工，他们是为房客工作的人。在我的示例数据中，我们看到Bob和Mary都适用于Barbie's Hair Salon和Greg，它们都在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 | ... |
| .. | ....... | ......... | .......... | .......... | ... |
+----+---------|-----------+------------+------------+-----+

我们需要一张能把雇员和租户联系在一起的桌子。这个表非常类似于customers_tenants表。在我的示例数据中，我们看到Bob在Ken's Gym上工作，Mary在Barbie's Hair Salon和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 |
| ........... | ......... |
+-------------+-----------+

在tenants表中，我们存储关于每个租户的信息。很明显，你将拥有的不仅仅是一个名字。

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

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

最后，我们有一个包含用户信息的表。由于customers和employees是users的子集，所以我们在这里存储所有公共信息，如first_name、last_name等。

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     | ... |
| .. | ........ | ........ | .......... | ......... | ... |
+----+----------+----------+------------+-----------+-----+