2

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

要求

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

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

选项 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 个不同的登录页面和身份验证请求类型。

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

4

2 回答 2

2

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

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

1）优点：

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

缺点：

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

2）优点：

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

缺点：

  • 随着新需求的到来，架构的重构永无止境
  • 如果项目存在足够长的时间，数据库就会充满“不再使用”的列（或其他数据库对象），没人想碰
  • 更难执行完整性

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

于 2013-09-13T15:50:26.533 回答
1

选项 1 对我来说看起来更好。

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

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

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

于 2013-09-13T13:10:24.760 回答