database-design - 以有效的方式将昵称和密码存储在 DBMS 中

Question

您会选择以下两个选项中的哪一个，为什么？
选项1:

Customer -> CustomerID_PK, DateOfBirth, Address, Username, Password

选项 2:

Customer -> CustomerID_PK, DateOfBirth, Address
CustomerInfos -> CustomerID_PK, Username, Password

您不知道经理存储每个客户以前的所有用户名和密码是否很重要。您只知道每个客户都可以随时更改他的密码和昵称。无论安全方面如何，您会采用哪种方法？

Answer 1

精心设计的数据库是相当不错的物理世界模型。所以，在决定像你这样的问题时，想想世界上发生了什么。
您的 entity这是客户。客户应该具有哪些属性？哪些属性本质上属于每个客户？客户是自然人，因此他们每个人都有唯一的出生日期。在您的系统中，每个客户都只有一个用户名和密码。所以这些是显而易见的属性。

用户名

密码

出生日期

您还可以决定您的客户只能拥有一个地址。或者，根据您的业务规则(家庭、办公室？)，客户可能有多个地址，如果您选择“恰好一个地址”业务规则，则地址也是您的客户实体的属性。如果没有，您有一个名为 Address 的单独实体，看起来像这样。 (类型是“家”、“办公室”等)。

(address_id PK, customer_id FK, type, address)

如果您需要为客户存储以前的用户名/密码组合，则需要一个单独的凭据实体。每个客户将拥有一个或多个凭证。所以凭证表看起来像这样。

(credential_id PK, customer_id FK, username, password, effective_date)

无论如何，为了数据工程的清晰度，您应该使用一张表来存储一个实体。所以，我建议选项1。
这是一个实用的建议。随着时间的推移，模​​式只会添加更多的表，所以避免额外的表是好的。包含具有相同代理(自动递增)主键的多个表的模式更难理解和维护，并且这些额外的表是不必要的。
异常(exception):您已经拥有数百万个客户，您需要添加更多属性，但您无法承受重新组织表和添加列的停机时间。