与自动递增的数字相比,电子邮件地址是一个糟糕的初选候选人吗?

我们的web应用程序需要电子邮件地址在系统中是唯一的。所以,我想到使用电子邮件地址为主键。然而,我的同事认为字符串比较将比整数比较慢。

这是一个有效的理由不使用电子邮件为主键吗?

我们使用的是PostgreSQL。


当前回答

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

其他回答

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

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

主键应该是唯一的常量

电子邮件地址随着季节的变化而变化。作为查找的辅助键很有用,但作为主键不太合适。

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

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

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