高效在DBMS中存储用户昵称与密码：两种数据库表结构方案的选择及理由说明

我会毫不犹豫地选方案2，核心原因是它的扩展性和数据职责分离更贴合当前需求以及未来可能的变化：

• 数据职责清晰，降低耦合
  Customer表专注存储用户的核心静态信息（出生日期、地址），这类信息通常变更频率极低；而CustomerInfos表专门存放可频繁修改的身份凭证（用户名、密码）。这种拆分符合数据库设计的单一职责原则，避免了因为频繁更新凭证数据而对核心用户表产生不必要的性能影响，也让表结构的语义更清晰。

• 完美适配未来可能的历史记录需求
  虽然现在不确定是否需要存储历史用户名和密码，但用户明确可以随时修改这些信息。如果用方案1，后续要支持历史记录会非常被动：要么在Customer表中添加大量冗余字段（比如OldUsername1、OldPassword1），这会让表结构变得臃肿且难以维护；要么新增独立的历史表，这时候还需要做数据关联和迁移，额外增加复杂度。
  而方案2的结构天然支持扩展：只需要对CustomerInfos表做简单调整（比如把主键改成CustomerID + Version的复合主键，新增IsCurrent字段标记当前生效的凭证），或者新增一张CustomerInfoHistory表来归档旧数据，就能轻松实现历史记录存储，完全不会影响核心的Customer表结构。

• 无额外维护负担
  就算短期内不需要历史记录，方案2的拆分也不会增加额外的维护成本。相反，在查询核心用户信息时，无需关联凭证表，能小幅提升查询效率；后续如果有安全相关的调整（比如单独加密凭证表），也能更方便地操作。

内容的提问来源于stack exchange，提问作者Jenny