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

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

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

我们使用的是PostgreSQL。


当前回答

字符串比较比int比较慢。但是,如果您只是使用电子邮件地址从数据库检索用户,那么这并不重要。如果您有多个连接的复杂查询,那么这很重要。

如果在多个表中存储有关用户的信息,则用户表的外键将是电子邮件地址。这意味着您将多次存储电子邮件地址。

其他回答

我对postgres不太熟悉。主键是一个很大的主题。我在这个网站(stackoverflow.com)上看到了一些很好的问题和答案。

我认为使用数字主键并在电子邮件列上使用UNIQUE INDEX可以获得更好的性能。电子邮件往往在长度上有所不同,可能不适合主键索引。

在这里和这里读点书。

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

你的同事是对的:使用一个自动递增的整数作为你的主键。

您可以在应用程序级别实现电子邮件唯一性,或者您可以将电子邮件地址列标记为惟一,并在该列上添加索引。

将字段添加为唯一字段只会在插入到该表时花费字符串比较的成本,而不会在执行连接和外键约束检查时花费字符串比较成本。

当然,您必须注意,在数据库级别向应用程序添加任何约束都可能导致应用程序变得不灵活。在仅仅因为应用程序需要某个字段是唯一的或非空的,就将它设置为“唯一的”或“非空的”之前,一定要充分考虑。

字符串比较比int比较慢。但是,如果您只是使用电子邮件地址从数据库检索用户,那么这并不重要。如果您有多个连接的复杂查询,那么这很重要。

如果在多个表中存储有关用户的信息,则用户表的外键将是电子邮件地址。这意味着您将多次存储电子邮件地址。

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