身份验证数据库字段

我正在将身份验证系统应用到现有的数据库系统中。目前，数据库有一个“Person”表，其中包含如下内容：名字，姓氏，出生日期，电子邮件（用户名）等。这是用户的主表。身份验证数据库字段

我需要添加以下字段进行身份验证：密码，IsLocked，LockDate，LastLoginDate。

你会建议把这些字段放在Person表中还是放在新的认证表中？我原来的计划是“人”只是简单地包含有关该人的数据，而不一定涉及认证。

另一种方法可能是将密码与电子邮件一起存储在Person中，但将验证数据放在单独的表中。这样，用户名和密码将在同一个地方，但元数据将在它自己的实体。

任何人有任何想法？感谢您的帮助！

来源

2012-05-02 user543936

保持帐户信息分开。您当前的业务需求可能是每个人只有一个账户，但未来可能会出现一个人需要拥有多个账户，或者甚至需要一个由多个人共享的账户。有一个单独的认证表意味着这样的未来的变化将对你的代码产生较小的影响。

此外，从保护认证信息的角度来看，可以访问帐户数据的人员/流程越少越好。实现表级访问比列级访问更容易。

来源

2012-05-02 16:49:23

感谢您的回复。使用这种方法，您将在哪里存储电子邮件地址？它在整个应用程序中使用，但也可以用作用户名。你会将它从Person抽象出来并放到Authentication表中吗？ – user543936

@ user543936 - 由于我上面提到的相同原因，我会将用户标识与电子邮件地址分开。在默认情况下，使用电子邮件地址作为用户ID可能是一个巧合或策略，但如果您引入组登录或电子邮件分发列表等，将来可能会随时更改。如果您有一条业务规则说明它们应该是同样，然后编写一点应用程序逻辑，在更新自动更新的应用程序逻辑之前进行检查（只要它们在编辑之前是相同的）。 –

我认为为身份验证数据创建一个单独的表是不太合理的。据我所知，身份验证不能独立于Person存在 - 并且似乎没有一个Person可以合理地与两个Authentications关联的方式（反之亦然）。

换句话说：Person和Authentication之间存在1：1的关系，那么为什么要将它分离？

来源

2012-05-02 16:35:50 Yuka

这个数据库有很多1：1的关系，但是我把它们拆分成逻辑实体。例如，我可以将所有用户的职业信息放入Person表中，但将它放在“职业”表中可能更有意义，因为它可能会扩展到更大的一些。我想我只是想避免在Person表中放入每个1：1的关系。我不想有一个100列的桌子......所以我试图尽早避免这个陷阱。 – user543936

我明白了;这是真的，你不想结束一个怪异的单桌。我仍然建议在主Person表中保留身份验证的内容，因为我觉得它与那里的信息（例如用户名）密切相关，但我可以看到这种情况。我想，这归结于个人偏好。 – Yuka

每个人可能有多重身份验证的原因。不同的角色可能需要一个人拥有2个或更多的密码。例如，一个可以让用户访问简单的用户，另一个可以让他访问管理员。 –

将它们保持分开，以便用户可以向系统查询有关Person的信息，而无需访问其帐户凭证。

这也有一个很好的副作用，并非所有Person实体可能有帐户。

来源

2012-05-02 16:36:47 Yuck

您可以通过创建适当的视图来让用户访问“Person”而不是“Authentication”数据，这不是什么大问题。 – Yuka

@Yuka True。但是，对于相关的属性拆分，该模型仍然更有意义。与“PersonContactInformation”或“PersonAddress”关系相同的想法。即使这个“人”总是只有**一个**，将所有内容都放在一张表中是没有意义的。 – Yuck

是啊......其实，（这个，以及ypercube说的。）我想我接近了这个错误。（+1） – Yuka

身份验证数据库字段

回答

相关问题