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

Question

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

要求

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

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

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

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

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

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

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

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

我真的很伤心，这是最好的方法。 有一个更好的方法吗？

Answer 1

我认为，两种方法都行得通。 第一个是更通用的，并且能够满足各种当前未知的要求。 如果选择它，我建议将角色的概念添加到模型中-“ user_type”是一个角色，并且一个用户可以[同时]与不同的角色相关联。 另外，Len Silverston的“数据模型资源书”也是一个很好的资源。

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

1）优点：

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

缺点：

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

2）优点：

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

缺点：

• 随着新需求的到来，架构的重构永无止境
• 如果项目寿命足够长，则数据库将充满“没人要使用”的列（或其他数据库对象）
• 难以执行诚信

我希望这是有道理的，并可以帮助您做出适合您需求的正确决定。

Answer 2

选项1在我看来更好。

当您不希望将学生与教练区分开时，它将简化您的代码，并且如果您要区分他们，则与选项2几乎相同。

如果您确实需要验证外键，则可以使用触发器来检查其是否为教练。

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