php - 数据库设计 : Multiple User Entities. 单表或多表

Question

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

要求

1. 教练和学生登录。
2. 教练可以专门为单个学生提供数字类(class)。

我不确定根据要求使用什么是最好的数据库模式。这里有两个选项:

选项 1
用户(PK id、用户类型(教练或学生)、名字、姓氏、电子邮件、密码等...)
类(class)(PK id、FK coach_user_id(引用:User.id)、FK student_user_id(引用:User.id)、lesson_name 等)

优点:
- 一张用户表
- 每个用户都有一个唯一的 ID 和电子邮件
- 使用单表简化登录验证

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

选项 2
教练(PK id、名字、姓氏、电子邮件、密码等...)
学生(PK id、名字、姓氏、电子邮件、密码等...)
类(class)(PK id、FK coach_id(引用:Coach.id)、FK student_id(引用:Student.id)、lesson_name、lesson_text 等)

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

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

我真的很纠结哪一个是最好的方法。有更好的方法吗？

Answer 1

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

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

1) 优点:

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

缺点:

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

2) 优点:

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

缺点:

• 随着新需求的出现，架构重构永无止境
• 如果项目生命周期足够长，数据库将充满“不再使用”的列(或其他数据库对象)，没人愿意碰
• 更难加强诚信

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