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

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

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

我们使用的是PostgreSQL。


当前回答

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

其他回答

这很糟糕。假设某个电子邮件提供商倒闭了。用户会想要更改他们的电子邮件。如果你使用e-mail作为主键,用户的所有外键都将复制该电子邮件,这使得更改它非常困难……

... 我甚至还没有开始谈论性能考虑因素。

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

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

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

您可能需要考虑任何适用的数据法规。电子邮件是个人信息,例如,如果你的用户是欧盟公民,那么根据GDPR,他们可以指示你从你的记录中删除他们的信息(记住,无论你在哪个国家,这都适用)。

如果出于参考完整性或审计等历史原因,需要将记录本身保存在数据库中,则使用代理键将允许您将所有个人数据字段设置为NULL。如果他们的个人数据是主键,这显然不那么容易

Email是一个很好的唯一索引候选,但不是主键,如果它是一个主键,例如,你将无法更改联系人的电子邮件地址。 我认为你的连接查询也会变慢。