0

我目前正在为我们学校开发一个新的数据库/网络应用程序。我需要提供一些背景信息，以使我的问题更具相关性。

有许多不同的用户类型将访问此应用程序，每个用户类型都需要访问应用程序的不同部分，对他们可能访问的每个“区域”具有不同的权限。

例如：

学生可以登录并访问那里的信息并更新他们的详细信息以及下载他们的报告副本（因此他们只能看到他们的信息）

老师可以登录并访问那里的信息以及他们教的所有学生

管理员可以登录并访问那里的信息以及他们管理的所有教师和学生

然后还有许多其他登录类型，但是对于这个问题，它们并不重要，因为从技术上讲，它们只是更多的用户，没有或需要自己的表来获取额外信息。

在很大程度上，我已经决定了一个我很满意的结构，但是我一直在改变我认为如何最好地完成以下工作的想法。

我有一个用户表（User_T），其中存储了所有相关的用户信息（用户名、密码等）

但是，我也为某些用户类型（EG、学生、员工、ETC）提供了单独的表，这是必要的，因为学生需要存储与员工不同的信息。这就是我的问题所在，所有用户都会有一些相同的基本字段（名字、姓氏、出生日期、性别等）。

我应该将这些存储在 User_T 表中吗？还是在个别表中？

如果我将它们全部存储在 User_T 表中，这使得应用程序更容易提取他们的信息并允许他们更新，例如在显示学生详细信息时，我需要引用 User_T 来获取学生姓名等.

我目前的心态是，最好的选择是使用包含所有字段的单独表并将它们连接到视图 User_V 中，并带有一个指示数据来源的字段，以便在执行更新时可以应用它适当的表。

想法？

4

1 回答 1

0

听起来可以通过使用 User_T 表作为一般的“人员”配置文件表和其他表作为独特的角色特定数据进行很好的分离。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, ...
于 2013-05-22T01:45:13.843 回答