数据库设计问题：多种类型的用户答案

【问题标题】：Database design issue : Multiple types of users数据库设计问题：多种类型的用户
【发布时间】：2013-05-02 11:16:39
【问题描述】：

我正在设计一个具有多种用户类型的数据库，即管理员、编辑、教师和学生。现在，所有这些用户都有一些公共字段 (CF) 和一些与他们关联的唯一字段 (UF)。我想知道这是不是一个好的设计？

表用户：[user_id (PK), CF1, CF2,..., CFN, user_type (enum)]

表管理员：[id (PK), UF_A1, UF_A2, ... , U_AN, user_id(FK)]

表格编辑器：[id (PK), UF_E1, UF_E2, ... , U_EN, user_id(FK)]

表教师：[id (PK), UF_T1, UF_T2, ... , U_TN, user_id(FK)]

表学生：[id (PK), UF_S1, UF_S2, ... , U_SN, user_id(FK)]

其中 UF_A、UF_E、UF_T 和 UF_S 是每个表的唯一字段。

现在我的问题是：

PS：如果它们可能有助于获得更好的洞察力，请补充几点：

【问题讨论】：

你如何评价“好”？
对不起，“好”是模棱两可的。我的意思是一种健壮、可扩展的设计，并遵循关系数据库设计的最佳实践。我之前没有任何数据库设计经验，所以我很害怕犯一个以后可能会非常昂贵的新手错误。
我会采用更“角色”的架构，这样 SELECTS 和 JOINS 就不会变成噩梦。用户表、角色表、user_role_vars 表。

【解决方案1】：

您的设计是关系数据库中三种公认的继承关系建模方式之一；其他的是“每个表的类”，其中每个子类都有自己的完整表，或者“一个表来统治它们”，其中所有可能的列都位于一个表中。

其他替代方法是使用 Entity-Attribute-Value 或文档（例如 JSON 或 XML）来存储数据。

您的设计有以下好处：

缺点：

【讨论】：

【解决方案2】：

您的设计 (Users.user_type) 暗示某个特定的人可以是管理员，也可以是编辑者，但不能同时兼任。这也意味着教师不能成为编辑。这是你的本意吗？

Admin.user_id、Editors.user_id、Teachers.user_id、Students.user_id 列通常是您所描述的结构类型中的主键。如果 CodeIgniter 不允许你将它们设为主键，你仍然需要声明它们是唯一的。

唯一字段的示例是 . . .教师（大学名称、大学标志、学历）

这可能不是真的。

例如，我如何确保 user_type 教师的用户不存储在学生表中？

具有重叠约束、默认值、检查约束和外键引用。这比听起来容易。见this SO answer。但我不相信你真的想这样做。

【讨论】：

【解决方案3】：

您的设计说明了一种称为class-table-inheritance 的设计技术。
此标签有一个概述该技术的信息选项卡。

正如信息所说，还有另一种可能有用的技术，即 shared-primary-key。

【讨论】：