我已经完成了许多Web应用程序，首先要做的是用用户名，密码，名称，电子邮件和所有其他常用的flotsam创建用户表。我当前的项目提出了这样一种情况，即非用户记录的功能需要类似于用户，但不需要具有一阶用户的能力。

创建第二个表" people_tb"是否合理，它是主要的关系表和数据存储区，并且仅使用" users_tb"进行身份验证？将" user_tb"与" people_tb"分开会不会有任何问题？如果通常这样做，那么有哪些策略和解决方案以及缺点？

解决方案

如果user_tb具有身份验证信息，我将使其与people_tb分开。但是，我会保持两者之间的关系，并且大多数用户的信息都将存储在people_tb中，除了auth所需的所有信息(我想不会将其用于其他用途)这是设计与效率之间的一个很好的折衷。思考。

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

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

然后对于登录的人，我们可以拥有一个"用户"表，该表与"人"具有1〜1的关系。该表可以存储用户名和密码。

这绝对是我们要做的，因为我们拥有数百万的用户记录并且只有数千个用户。我们还将地址，电话和电子邮件分离到关系表中，因为许多人不但拥有这些东西中的每一个。关键是不要依赖名称作为标识符，因为名称不是唯一的。确保通过某种类型的代理键(最好是整数或者GUID)而不是名称来联接表。

我会说要进行规范化的设计(两个表)，并且只有进行非规范化(下到一个用户/人表)，才能真正简化工作。但是，如果实际上所有人都是用户，则预先进行非规范化可能会更简单。由你决定;我使用标准化方法没有问题。

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

我们将遇到的问题是，每当我们使用用户表时，我们几乎总是希望人员表获得我们想要显示的名称或者其他公共属性。

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

在我的应用程序中，我正在用Ruby on Rails编写代码，因此我一直在执行诸如employee.user.name之类的事情，如果将它们放在一起，则只会是employee.name或者user.name。

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

我们还可以在数据库中创建一个视图，以使两个表保持连接在一起，从而为我们带来更多的性能增强。我知道在更高版本的Oracle中，如果需要提高性能，甚至可以在视图上放置索引。

很合理

例如，在这里查看aspnet_ * services表。

他们的内置模式具有一个" aspnet_Users"和" aspnet_Membership"，后面的表具有有关给定用户的更多扩展信息(哈希密码等)，但是在模式的其他部分使用" aspnet_User.UserID"以确保引用完整性等等。

最重要的是，如果属性是不同的实体，那么将属性放在单独的表中是很常见的，并且设计很好，就像我们所遇到的情况一样。