数据库设计：多用户实体。单个或多个表答案

【问题标题】：Database Design: Multiple User Entities. Single or Multiple Tables数据库设计：多用户实体。单个或多个表
【发布时间】：2016-03-25 20:56:06
【问题描述】：

我正在构建一个具有 3 种基本实体类型的 PHP 应用程序：教练、学生、课程，其中教练为学生创建数字课程。我正在使用 MySQL 和 innoDB 表。

要求

我不确定根据要求使用的最佳数据库架构是什么。这里有两个选项：

选项 1
用户（PK id、user_type（教练或学生）、名字、姓氏、电子邮件、密码等...）
课程（PK id、FK coach_user_id（参考：User.id）、FK student_user_id（参考：User.id）、课程名称等...）

优点：
- 一个用户表
- 每个用户都有一个唯一的 ID 和电子邮件
- 使用单表使登录验证变得容易

缺点：
- 当教练或学生 User.id 在课程表中记录为 FK 时，不验证 user_type。此问题将在需要将教练或学生 User.id 记录为 FK 的任何新表中再次出现。
- 潜在的多态性问题和规范化的需要。

选项 2
教练（PK id、名字、姓氏、电子邮件、密码等...）
学生（PK id、名字、姓氏、电子邮件、密码等...）
课程（PK id、FK coach_id（参考：Coach.id）、FK student_id（参考：Student.id）、课程名称、课程文本等）

优点：
- 规范化的数据库模式。独立教练、学生实体表。
- 没有用户类型验证问题。 Coach ID 和Student ID FK 分别独立指向Coach.id 和Student.id。

缺点：
- 教练和学生可以拥有相同的ID。（这可以通过 ID 前缀来解决，例如 C1001、S1001）
- 教练和学生可以使用相同的电子邮件。
- 登录身份验证涉及查询两个 2 表的单个登录页面，或创建 2 个不同的登录页面和身份验证请求类型。

我真的很伤心，这是最好的方法。有没有更好的方法来做到这一点？

【问题讨论】：

【解决方案1】：

在我看来，你的两种方法都行得通。第一个更通用，能够适应各种目前未知的需求。如果你选择它，我建议在模型中添加角色的概念——“user_type”是一个角色，一个用户可以[同时]与不同的角色相关联。此外，Len Silverston 的“数据模型资源书”是一个很好的资源。

但是，您可能并不总是希望架构过于笼统。您在非常低的级别上列出了 2 种方法的优缺点；我认为实用性比特定的技术问题（可以克服）更重要。我会这样说的：

1) 优点：

缺点：

2) 优点：

缺点：

我希望它是有意义的，可以帮助您做出适合您需求的正确决定。

【讨论】：

所以从选项 1 中删除 User.user_type 然后创建 Role 和 User_Role 表以允许多对多关系？你有更多关于这方面信息的网站吗？ ;)
角色表本身只是定义了不同的角色，如“学生”、“教练”等。然后我们需要user_role 链接表。在某些情况下，仅包含 user_id、role_id 字段就足够了（带有 UNIQUE(user_id, role_id)）。在其他情况下，您可能想要添加日期——从开始到结束——例如，user1 是 2012 年的学生，然后他成为教练等。然后你需要另一个唯一的约束，不是UNIQUE(user_id, role_id)，而是UNIQUE(user_id, role_id, date_from)。跨度>

【解决方案2】：

选项 1 在我看来更好。

当您不想区分学生和教练时，它将简化您的代码，如果您想区分它们，它将与选项 2 几乎相同。

如果你真的需要验证外键，你可以使用触发器来检查它是否是教练。

我不确定您所说的“潜在的多态性问题和规范化的需要”是什么意思。。

【讨论】：