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

Question

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

要求

1. 教练和学生登录。
2. 教练可以专门为单个学生提供数字课程。

我不确定在给定要求的情况下使用哪种最佳数据库架构。这有两个选择：

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

优点：
- 一个用户表
- 每个用户都有一个唯一的ID和电子邮件
- 使用单个表格轻松登录auth

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


选项2
教练（PK id，名字，姓氏，电子邮件，密码等......）
学生（PK id，名字，姓氏，电子邮件，密码等......）
课程（PK id，FK coach_id（ref：Coach.id），FK student_id（ref：Student.id），lesson_name，lesson_text等......）

优点：
- 规范化数据库架构。独立教练，学生实体表 - 没有用户类型验证问题。教练ID和学生ID FK分别独立于Coach.id和Student.id。


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


我真的被撕裂了，这是最好的方式。有更好的方法吗？

Answer 1

在我看来，你的两种方法都有效。第一个是更普遍的，并且能够适应各种当前未知的要求。如果你选择它，我建议在模型中添加Role的概念 - “user_type”是一个角色，一个用户可以[同时]与不同的角色相关联。此外，Len Silverston的“数据模型资源手册”是一个很好的资源。

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

1）优点：

• 轻松容纳新功能而无需对架构进行重大更改
• 非常灵活
• 易于在架构之上构建多维数据集
• 适合长期项目

缺点：

• 需要更多资源（经验丰富的DBA /数据模型专家[s]，相对较长的设计时间）
• 比（2）
更复杂的方式

2）优点：

• 快速交付第一个工作版本
• 即使非技术人员（直到长大）也很容易理解
• 适合小型项目或具有明确定义的域名的项目，这些域名几乎永远不会改变

缺点：

• 永远不会在新要求出现时结束架构的重构
• 如果项目足够长，数据库就会充满“不再使用”列（或其他数据库对象）没人想触摸
• 更难以执行诚信

我希望它有意义并帮助您做出符合您需求的正确决定。

Answer 2

选项1对我来说更好看。

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

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

我不确定你的意思“潜在的多态性问题以及规范化轨道的必要性。”。