我目前正在为我们学校开发一个新的数据库/网络应用程序。我需要提供一些背景信息，以使我的问题更加相关。
有许多不同的用户类型将访问此应用程序，每个用户都需要访问应用程序的不同部分，并为每个可能访问的“区域”提供不同的权限。
例如：
学生可以登录并访问该信息并更新其详细信息以及下载其报告副本（因此他们只能看到他们的信息）
教师可以登录并访问其中的信息以及他们教授的所有学生
经理可以登录并访问他们所管理的所有教师和学生的信息
然后有一堆其他登录类型，但是对于这个问题，它们并不是真正重要，因为它们在技术上只是更多用户没有或需要他们自己的表来获取额外信息。
我在很大程度上决定了一个我很满意的结构，但是我一直在改变我的想法，我认为以下是最好的。
我有一个用户表（User_T），其中存储了所有相关的用户信息，（用户名，密码等）
但是，对于某些用户类型（EG，学生，员工，ETC），我也有单独的表格，这是必要的，因为学生需要存储的信息与工作人员不同。 这就是我的问题所在，所有用户都将拥有一些相同的基本字段（名字，姓氏，出生日期，性别等）。
我应该将这些存储在User_T表中吗？或者在各个表中？
如果我将它们全部存储在User_T表中，这样可以让应用程序更容易获取信息并允许它们更新，例如，在显示学生详细信息时，我需要引用User_T以获取学生姓名等。
我目前的心态是，最好的选择是让所有字段都有单独的表，并将它们连接到User_V视图中，并带有一个指示数据来源的字段，以便在执行更新时它可以适用于适当的表格。
思想？
答案 0 :(得分：0)
通过将User_T表用作一般的“people”配置文件表以及用于唯一角色特定数据的其他表，听起来会有很好的分离。 User_T将存储有关此人的更一般信息，此表中的ID可能是其他表中名为“person_id”的外键。
使用此表架构还取决于您可以一起查询此共享常规数据的频率。例如，如果您计划在不知道类型/角色（无论是员工，学生等）的情况下搜索姓名或电子邮件，那么在User_T表中将此一般人员信息与其他信息分开是一件好事。如果您知道角色/类型，则可以选择要搜索的相应表，并根据需要为User_T数据添加。但是如果你不以这种方式分离你的表，那么你可以使用VIEW或UNION来只搜索那些只有一个查询的常规列，在我看来，优化要麻烦得多。
User_T table: id, first_name, last_name, email, gender, birthdate, role, ...
Students table: id, person_id, gpa, ...
Staff table: id, person_id, staff_type, hire_date, ...