将关系数据库中的用户表与人员表分开

Question

我开发过许多网络应用程序，其中您要做的第一件事就是创建一个用户表，其中包含用户名、密码、姓名、电子邮件和所有其他常见的废物。我当前的项目提出了一种情况，非用户记录需要与用户类似地发挥作用，但不需要成为一阶用户的能力。

创建第二个表是否合理， people_tb, ，即主要的关系表和数据存储，并且仅使用 users_tb 用于身份验证？是否分离 user_tb 从 people_tb 存在任何问题吗？如果普遍这样做，有哪些策略和解决方案以及缺点？

Answer 1

这当然是一个好主意，因为您正在标准化数据库。我在我正在编写的应用程序中做了类似的设计，其中有一个员工表和一个用户表。用户可能来自外部公司或员工，因此我有单独的表，因为员工始终是用户，但用户可能不是员工。

您将遇到的问题是，每当您使用用户表时，您几乎总是希望人员表获取您想要显示的姓名或其他常见属性。

从编码的角度来看，如果您使用直接 SQL，则需要花费更多的精力来解析 select 语句。如果您使用 ORM 库，情况可能会更复杂一些。我对这些没有足够的经验。

在我的应用程序中，我使用 Ruby on Rails 编写它，因此我不断地执行诸如 employee.user.name 之类的操作，如果我将它们放在一起，那么它就只是 employee.name 或 user.name。

从性能的角度来看，您遇到的是两个表而不是一个，但如果有适当的索引，它应该可以忽略不计。例如，如果您有一个包含主键和人员姓名的索引，则数据库将命中用户表，然后命中人员表的索引（几乎直接命中），因此性能几乎与有一张桌子。

您还可以在数据库中创建一个视图，将两个表连接在一起，从而提高性能。我知道在 Oracle 的更高版本中，如果需要提高性能，您甚至可以在视图上放置索引。

Answer 2

我经常这样做，因为对我来说，“用户”（用户名、密码、创建日期、上次登录日期）的概念与“人”（姓名、地址、电话、电子邮件）不同。您可能会发现的缺点之一是您的查询通常需要更多联接才能获取您要查找的信息。例如，如果您只有登录名，则需要加入“people”表以获取名字和姓氏。如果您将所有内容都基于用户 ID 主键，则此问题会有所缓解，但仍然会弹出。

Answer 3

如果 user_tb 有身份验证信息，我非常会将其与 people_tb 分开。然而，我会保持两者之间的关系，并且大多数用户的信息将存储在 people_tb 中，除了身份验证所需的所有信息（我猜不会用于其他用途），这是设计和效率之间的一个很好的权衡思考。

Answer 4

我总是尽力避免尽可能多的数据重复。如果不是所有人都需要登录，您可以使用通用的 people 包含适用于人员和用户的信息的表（例如名字、姓氏等）。

然后对于登录的人，您可以拥有 users 与 1~1 关系的表 people. 。该表可以存储用户名和密码。

Answer 5

我想说的是，如果真的能让你的生活变得更轻松，就采用规范化设计（两个表），并且只进行非规范化（下降到一个用户/人表）。然而，如果实际上所有人都是用户，那么预先进行非规范化可能会更简单。由你决定;我使用标准化方法没有问题。

Answer 6

非常合理。

作为示例，看一下 aspnet_* 服务表 这里.

他们的内置模式有一个 aspnet_Users 和 aspnet_Membership 后面的表包含有关给定用户的更多扩展信息（哈希密码等），但 aspnet_User.UserID 用于架构的其他部分以实现引用完整性等。

最重要的是，如果属性是不同的实体，那么将属性放在单独的表中是非常常见且良好的设计，就像您的情况一样。

Answer 7

这绝对是我们所做的，因为我们拥有数百万人的记录，但只有数千名用户。我们还将地址、电话和电子邮件分成关系表，因为许多人都拥有不止一项这些内容。关键是不要依赖名称作为标识符，因为名称不是唯一的。确保通过某种类型的代理键（最好是整数或 GUID）而不是名称来连接表。