似乎没有人提到一个可能的问题，即电子邮件地址可能被视为隐私。如果电子邮件地址是主键，那么个人资料页面的URL很可能类似于..../Users/my@email.com。如果不想暴露用户的电子邮件地址怎么办?您必须找到其他一些识别用户的方法，可能是通过一个唯一的整数值来生成像..../Users/1这样的url。那么你最终会得到一个唯一的整数值。

就我个人而言，我在设计数据库时不使用任何信息作为主键，因为我很可能在以后需要更改任何信息。我提供主键的唯一原因是，它方便从客户端执行大多数SQL操作，我的选择一直是自动增加整数类型。

不要使用电子邮件地址为主键，保持电子邮件的唯一性，但不要使用它为主键，使用用户id或用户名为主键

主键应该选择一个静态属性。由于电子邮件地址不是静态的，可以被多个候选人共享，因此使用它们作为主键并不是一个好主意。此外，电子邮件地址通常是一定长度的字符串，可能大于唯一id，我们想使用[len(email_address)>len(unique_id)]，所以它将需要更多的空间，甚至最糟糕的是，它们被多次存储为外键。因此会导致性能下降。

我知道这有点晚了，但我想补充的是，人们放弃电子邮件帐户和服务提供商恢复地址，允许其他人使用它。

正如@HLGEM指出的那样，“Jsmith@somecompany.com很容易在一年后属于约翰·史密斯，两年后属于朱莉娅·史密斯。”在这种情况下，如果约翰·史密斯想要你的服务，你要么拒绝使用他的电子邮件地址，要么删除所有与朱莉娅·史密斯有关的记录。

如果你必须根据当地法律删除与企业财务历史有关的记录，你可能会发现自己陷入困境。

所以我永远不会使用电子邮件地址、车牌等数据作为主键，因为无论它们看起来多么独特，它们都不受你的控制，并且可能会提供一些你可能没有时间处理的有趣挑战。

我还要指出，电子邮件是一个糟糕的选择，使一个独特的领域，有些人，甚至是小企业共享一个电子邮件地址。和电话号码一样，电子邮件也可以重复使用。Jsmith@somecompany.com很容易属于一年前的约翰·史密斯，两年后的茱莉亚·史密斯。

电子邮件的另一个问题是它们经常变化。如果你用这个键连接到其他表，那么你也必须更新其他表，当整个客户公司更改他们的电子邮件时，这可能会对性能造成相当大的影响(我曾经见过这种情况)。