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

Question

我做了很多网络应用程序，你要做的第一件事就是用一个用户名，密码，名字，电子邮件和所有其他常用的flotsam制作用户表。我当前的项目提出了一种情况，即非用户记录需要与用户类似地运行，但不需要能够成为一阶用户。

创建第二个表people_tb是主要的关系表和数据存储是否合理，并且仅使用users_tb进行身份验证？将user_tb与people_tb分开会出现问题吗？如果这是常见的，那么一些策略和解决方案以及缺点是什么？

Answer 1

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

您将遇到的问题是，无论何时使用用户表，您几乎总是希望person表获取您想要显示的名称或其他常用属性。

从编码的角度来看，如果您使用的是直接SQL，那么精神上解析select语句需要花费更多的精力。如果您使用的是ORM库，可能会有点复杂。我没有足够的经验。

在我的应用程序中，我在Ruby on Rails中编写它，所以我经常做像employee.user.name这样的事情，如果我把它们放在一起，那就是employee.name或user.name。

从性能的角度来看，你打两个表而不是一个，但是如果给出了适当的索引，它应该可以忽略不计。例如，如果你有一个包含主键和人名的索引，那么数据库会点击用户表，然后是人员表的索引（几乎直接命中），所以性能几乎与有一张桌子。

您还可以在数据库中创建一个视图，以使两个表连接在一起，从而为您提供额外的性能增强。我知道在Oracle的更高版本中，如果需要提高性能，您甚至可以在视图上添加索引。

Answer 2

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

Answer 3

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

Answer 4

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

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

Answer 5

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

Answer 6

我会说去标准化的设计（两个表），只有非规范化（下到一个用户/个人表），如果它真的会让你的生活更轻松。然而，如果实际上所有人都是用户，则可能更容易在前面进行非规范化。由你决定;我没有问题地使用了规范化的方法。

Answer 7

非常合理。

举个例子，看一下aspnet_ *服务表here。

他们的内置架构有一个aspnet_Users和aspnet_Membership，后面的表有更多关于给定用户的扩展信息（散列密码等），但aspnet_User.UserID用于另一个参考完整性等模式的一部分。

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