这取决于桌子。如果表中的行表示电子邮件地址，那么电子邮件是最好的ID。如果不是，那么电子邮件不是一个好的ID。

整数主键更好的另一个原因是当您在不同的表中引用电子邮件地址时。如果address本身是一个主键，那么在另一个表中你必须使用它作为一个键。所以你可以多次存储电子邮件地址。

我不知道这在您的设置中是否可能是一个问题，但根据您的RDBMS，列的值可能是区分大小写的。PostgreSQL文档说:“如果你声明一个列为UNIQUE或PRIMARY KEY，隐式生成的索引是区分大小写的”。换句话说，如果您在一个以email为主键的表中接受用户输入进行搜索，并且用户提供“John@Doe.com”，那么您将找不到“john@doe.com”。

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

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

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

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

使用GUID作为主键…这样，当你执行INSERT操作时，你就可以从程序中生成它，而不需要从服务器获取响应来找出主键是什么。它在所有表和数据库中都是唯一的，如果有一天你截断了表，自动增量被重置为1，你不必担心会发生什么。

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