数据库设计：电子邮件作为表的 id答案

【问题标题】：Database design: Email as table's id数据库设计：电子邮件作为表的 id
【发布时间】：2011-02-06 06:46:07
【问题描述】：

我正在开发一个 Java Web 应用程序。对于身份验证，我要求用户输入他的电子邮件和密码。现在，我正在使用 JPA 2，这可能不是那么重要。
如果电子邮件是用户表的键，它将大大简化我的生活。我可以做一个简单的：

User selected = em.find(User.class, userEmail);

看到了吗？此外，每个电子邮件地址都是唯一的，没有空格等。现在，没有人这样做，我猜这是有原因的。我也有疑问，我的意思是，它是 varchar 等。但你认为这是个好主意吗？如果不是，为什么？这必须是一个很好的理由，这样权衡是不值得的。数字键总是最好的，但在这里我发现自己一遍又一遍地处理用户的电子邮件，并且一直通过电子邮件搜索它们，除了连接列等之外，从不真正使用 id。

【问题讨论】：

我认为这可能是我没有想得太远，我可能有成千上万的用户和数以百万计的连接，而 varchar 键与数字键会导致空间浪费，但是还有其他原因吗？
嗯。我只是自己回答。主键永远不应该改变，用户可以改变他的电子邮件。我想这是最大的原因。我应该删除我的问题还是让其他人看到以防他们有这个疑问
把它留在这里 - 下面出现的答案将对其他人有所帮助。
请记住，您可以在 SO 上回答您自己的问题......就像是一个实际的答案！！！如果您将来提出问题并自己回答，请随时发布并接受它:)

标签： java sql database jpa database-schema

【解决方案1】：

想到的最大问题是用户的电子邮件地址会随着时间而改变。如果您设置了一个以电子邮件地址为主键的系统，那么稍后更改电子邮件地址将是一件非常痛苦的事情——您必须将更改传播到所有子表，这将要求所有外键约束都是可延迟的.

【讨论】：

【解决方案2】：

除了

浪费空间。
联接中的性能问题。
在索引中浪费空间。

如果用户可以选择更改他的电子邮件 ID，您最终将更改主键，这将是一个很大的努力/混乱。

【讨论】：

【解决方案3】：

一个表可以有多个键。使电子邮件成为候选键。我喜欢把 PK 想象成竞选美国总统。您有多个候选人，但只有 1 个可以担任总统。

别人说的很好。如果值发生变化，您不想更新 30 个其他表。这有利于代理键（除了标识行之外没有任何意义的键）。由于代理没有任何意义，因此您不必担心它们的值会发生变化。通常它们是一个自增整数。

回到原点。你的代码：

User selected = em.find(User.class, userEmail);

无论电子邮件是主键还是候选键，该代码都应该完全有效。如果您的框架需要搜索主键，那么您最好运行尖叫，因为在现实世界中您搜索的不仅仅是 PK。

【讨论】：

它不需要您搜索主键，但它提供了以非常简单的方式进行搜索的工具，例如该语句。