Database 在关系数据库中分离用户表和人员表

我做过很多网络应用程序，你要做的第一件事就是创建一个包含用户名、密码、姓名、电子邮件和所有其他常见垃圾的用户表。我当前的项目呈现了这样一种情况：非用户记录的功能需要与用户类似，但不需要具备成为一级用户的能力

---

创建第二个表

people\u tb

，作为主要的关系表和数据存储，并且只使用

users\u tb

进行身份验证是否合理？将

user\u tb

与

people\u tb

分离是否存在任何问题？如果经常这样做，有哪些策略和解决方案以及缺点

如果用户\u tb有身份验证信息，我会将其与用户\u tb分开。然而，我会保持两者之间的关系，大多数用户的信息将存储在people_tb中，除了auth所需的所有信息（我猜不会用于其他很多信息）我认为这是设计和效率之间的一个很好的折衷。

我经常这样做，因为对我来说，“用户”的概念（用户名、密码、创建日期、上次登录日期）与“人”（姓名、地址、电话、电子邮件）不同。您可能会发现的一个缺点是，您的查询通常需要更多的加入才能获得所需的信息。如果您只有一个登录名，则需要加入“人”表以获取名字和姓氏为例。如果您以用户id主键为基础，这会有所缓解，但仍然会弹出。我总是尽量避免重复数据。如果不是所有人都需要登录，您可以使用一个通用的

人员
表，其中包含适用于两个人的信息d用户（例如firstname、lastname等）

然后，对于登录的用户，您可以有一个
用户
表，该表与
人
有1~1关系。该表可以存储用户名和密码。
这肯定是我们要做的，因为我们有数以百万计的用户记录，只有数千个用户。我们还将地址、电话和电子邮件作为人分离到关系表中每个人都有不止一个。关键是不要依赖名称作为标识符，因为名称不是唯一的。请确保表是通过某种类型的代理键（最好是整数或GUID）而不是名称连接的。
我要说的是，采用规范化设计（两个表），只进行非规范化（转到一个用户/个人表）如果它真的能让你的生活更轻松。但是，如果实际上所有人都是用户，那么预先去规范化可能会更简单。这取决于你；我使用规范化方法没有问题。
这当然是个好主意，因为你正在规范化数据库。我在我正在编写的一个应用程序中做了类似的设计，其中我有一个employee表和一个user表。用户可能来自外部公司或员工，因此我有单独的表，因为员工始终是用户，但用户可能不是员工

您将遇到的问题是，无论何时使用user表，您几乎总是希望person表获得希望显示的名称或其他公共属性

从编码的角度来看，如果您使用的是纯SQL，那么在精神上解析select语句将需要更多的努力。如果您使用的是ORM库，则可能会更复杂一些。我没有足够的经验

在我的应用程序中，我是用RubyonRails编写的，所以我一直在做employee.user.name之类的事情，如果我把它们放在一起，就只有employee.name或user.name了

从性能的角度来看，您正在访问两个表而不是一个表，但是如果给定适当的索引，则可以忽略不计。例如，如果您有一个包含主键和人名的索引，则数据库将访问用户表，然后访问人名表的索引（几乎直接访问），因此性能几乎与拥有一张桌子相同

您还可以在数据库中创建一个视图，将两个表连接在一起，以增强性能。我知道，在Oracle的更高版本中，如果需要提高性能，您甚至可以在视图上添加索引。
非常合理

作为一个例子，请看一下aspnet_*services表

他们的内置模式具有
aspnet\u用户
和
aspnet\u成员资格
，后面的表具有关于给定用户的更多扩展信息（散列密码等），但是
aspnet\u用户。UserID
用于模式的其他部分以实现引用完整性等

总之，如果属性是不同的实体，那么在一个单独的表中使用属性是很常见的，也是很好的设计，就像您的情况一样。
请注意，UUID（MS land中的GUID）实际上在许多情况下都是糟糕的键，因为它们的随机性和大小会破坏索引机制。最好尽可能使用简单的整数。