mysql - 在为 SaaS 应用程序设计数据库架构时需要帮助

Question

我是一名开发人员，之前从未从事过数据库工作(设计数据库)。我正在为员工管理系统设计一个数据库，该系统是一个使用 MySQL 作为其数据库的 Node.js + Express 应用程序。

我已经有了所需的表格和列，但我要处理的未知数仍然很少。这是我目前的计划，我需要你的意见。

1. 使用此应用程序的最终用户将是中小型公司。这些公司不会共享数据库中的表。因此，如果有一个名为 EmployeeCases 的表，我计划为每个现有公司或注册此应用程序的新公司创建一个新的 EmployeeCases 表。我打算将该表命名为 EmployeeCases_989809890 ，其中“989809890”将是公司 ID(或客户 ID)。因此，如果我们有 3-4 家公司为我们注册，那么所有表(至少是公司使用的表)都将被重新创建并命名为 TableName_CompanyId。我的问题，这是一个好方法吗？有没有更好的办法？

2. 员工的所有数据都保存在 Employee 表中，包括他们的登录名和密码。现在，DB 中的每个 Employee 表都将被命名为 Employee_CompanyId(按照我上面的计划)。我的问题是，当员工登录时，我如何知道要查询哪个 Employee 表？或者我应该从 Employee 表中删除登录名并创建一个通用的 Users 表来存储所有员工？ Users 表也将 CompanyId 作为其列之一，我将从那里读取 CompanyId，它将用于查询其他表。

任何关于此类设计的引用资料、网站或博客将不胜感激。

谢谢。

Answer 1

我不推荐这种方法，我认为你应该:

A) 将所有信息放在同一个表中，并有一个 companyId 列来排序

或

B) 每个公司都有单独的数据库，并使用代码使用适当的数据库。

问题是，使用您的方法，如果您有同一个表的多个不同名称的副本，您将很难维护您的应用程序。例如，如果您决定向其中一个表添加一列，则必须编写与表实例一样多的 SQL 脚本。您的所有唯一标识符也会很糟糕。

以下是每种设计的一些优点/缺点:

A) 将所有信息放在同一个表中，并有一个 compagnyId 列来排序

优点:

• 最简单
• 允许使用外键/约束
• 非常适合跨/客户端数据提取

缺点:

• 不可移植(客户不能带着他/她的数据离开)
• 可能被认为不太安全(我猜你可以用两种方式来说明)
• 更有可能拥有巨大的 table
• 不能很好地扩展

B) 每个公司都有单独的数据库，并使用代码使用适当的数据库。

优点:

• 便携
• 可以被认为更安全

缺点:

• 需要更多的纪律来跟踪所有的数据库
• 需要很好地区分 HUB(跟踪哪个客户端访问哪个数据库的应用程序)的组成部分以及客户数据库的组成部分。
• 您需要一个按公司分类的登录页面(或者让您的客户在一个字段中指定公司)

使用此“两步登录”的应用程序示例是 Slack ，当您登录时，您首先输入您的团队域，然后输入您的用户凭据。

我认为Google Apps for Work作为相同的方法。此外，我认为我合作过的大多数 CRM 都有一个单独的数据库供他们的客户使用。

最后，我想将您转至 this other question on stackoverflow链接到一个有趣的例子。