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

Question

我正在设计一个拥有多种类型用户的数据库，即管理员，编辑，教师和学生。现在，所有这些用户都有一些公共字段（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是每个表的唯一字段。

现在我的问题是：

1. 这是一个好设计吗？如果没有，你将如何设计它？
2. 如何确保user_type教师的用户不在学生表中存储？

PS：如果他们可能有助于获得更好的洞察力，还有更多要点：

1. 数据库将与codeigniter一起使用。
2. CF的例子有：用户名，密码，电子邮件，个人资料图片
3. 独特字段的示例包括：学生（年龄，入学人数），教师（大学名称，大学徽标，学位）

Answer 1

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

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

您的设计具有以下优势：

• 一致性：始终存储和管理公共数据;一旦你编写了密码规则，你就知道它们将被应用到任何地方。
• 可维护性：很清楚哪些数据存在于何处，并且它允许您对子类使用微妙的不同实现（存储教师的名称可能需要包括标题 - “Dr.”，存储学生的姓名可能不会）。
• 性能：在数据结构上运行关系查询应该很快（“找到12到14岁之间没有注册号码的所有学生”）;这对EAV或文档解决方案来说非常棘手。

缺点：

• 创建新的子类可能需要创建一个新表（这是EAV和文档解决方案经常获胜的地方）。
• 查询子类可能很棘手（“查找1990年以后出生或者拥有斯坦福大学学位的所有用户”）。这就是“一张大桌子”经常获胜的地方。
• 某些关系不容易使用“标准”关系工具（如唯一键，外键等）进行建模 - 例如，“您是学生或教师，但不是两者”的例子。您可以使用触发器或应用程序逻辑。
• 多重继承 - 用户可能是两者，例如编辑和教师 - 可能会变得混乱。

Answer 2

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

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

Answer 3

您的设计（Users.user_type）意味着某个人可以是管理员，或者该人可以是编辑，但不能同时为两者。这也意味着教师不能成为编辑。那是你的意图吗？

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

  

唯一字段的示例是。 。 。老师（大学名称，大学徽标，学位）

这可能不是真的。

  

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

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