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

Question

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

表的用户：[USER_ID（PK），CF1，CF2，...，CFN，USER_TYPE（枚举）]

表管理：[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. 该数据库将与笨使用。 CF的
2. 的例子是：用户名，密码，电子邮件，个人资料图片
独特领域的
3. 例子是：学生（年龄，报名号），教师（大学名，大学的标志，学位。）

Answer 1

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

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

独特的领域的例子是。 。 。教师（大学名，大学标志，学位）

这可能不是真的。

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

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

Answer 2

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

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

Answer 3

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

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

你的设计有以下好处：

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

缺点：

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