2

使用电子邮件地址作为主键的做法是什么？我应该避免它并使用自动递增的 ID 号，还是引擎也能够处理它？

MySQL 数据库，但我对其他引擎如何处理这个感兴趣（特别是 PostgreSQL）。

4

5 回答 5

8

您应该始终拥有一个没有商业价值的唯一整数主键。然后将其称为代理键。

您应该将电子邮件地址本身存储在另一个字段中，通常带有索引，以便它可以充当查找的键。

这将使您能够提供基于使用电子邮件地址进行查找来定位用户的功能。那时的任何其他功能都会使用该记录的主键进行其他操作，例如更新用户地址。

于 2013-11-23T20:07:46.723 回答
4

仅在满足一组相当狭窄的标准时才使用电子邮件地址是完全合理的：

  • 电子邮件地址是主要实体，它不识别其他内容（例如用户帐户）
  • 对表的 FK 引用相对较少，或者没有连接的快速 FK 查找至关重要
  • 您不会以任何方式验证电子邮件地址

换句话说，使用电子邮件地址作为主键是非常不合适的。我真正能想到的唯一明智的情况是处理邮件流的软件，它想要记录每个电子邮件地址的统计信息。

如果您正在考虑将其用作用户的标识符，请不要这样做。

电子邮件地址本身就是主要实体

您没有使用电子邮件地址来识别其他内容，例如用户帐户，而是有一个关于电子邮件地址的表格。比如说，您正在跟踪每个地址有多少消息进出。如果您要使用电子邮件地址识别其他内容，请不要将其用作主键。如果没有完美稳定的小而简单的自然键，请使用代理键。姓名和电子邮件地址发生变化。

外键引用相对较少

没有太多对以电子邮件地址作为主键的表的 FK 引用，或者您需要在具有 FK 的表中进行非常快速且无连接的查找。如果您直接在一个表中搜索一个值（电子邮件），而不是加入另一个表并测试另一个表的值，您可以获得很大的性能优势。这里的另一面是，使用电子邮件地址而不是生成的代理键会增加表所需的存储空间（因此：更大、更慢的表和索引），因此只有在您真的希望大量搜索外键时才值得。

您不验证电子邮件地址

如果您有“有效”或“无效”电子邮件地址这样的概念，您的规则迟早会改变，如果您使用电子邮件地址作为主键，您将处于悲惨境地。

电子邮件地址很奇怪

这三个电子邮件地址是相同的：

user.name@DOMAIN.COM
user.name@DoMAIN.CoM
user.name@domain.com

但这三个都是不同的：

user.name@domain.com
USER.NAME@domain.com
User.Name@domain.com

根据相关的 RFC。一些 MTA 同意，其他人则不区分大小写地处理整个事情。

是的。不要将它们用作 PK。

于 2013-11-24T01:31:14.917 回答
1

使用自动递增的主键。您不需要向用户公开此信息，您可以直观地表示它，就好像关键是电子邮件地址一样，但您需要内部一致且不随时间变化的数字。

请记住，您的主键用于链接到其他表，因此如果有人更改了他们的电子邮件地址，您还必须更新所有相关链接。这是极难做到的。

无论您使用什么 SQL 数据库，它们的工作方式都大致相同，并且具有相似的限制。

于 2013-11-23T20:11:30.883 回答
0

不使用业务信息作为主键而是使用代理主键的一个重要原因是外键。假设某人的电子邮件地址需要更新。你能想象更新密钥中的所有信息会是多么痛苦吗？如果您的外键足够严格，您可能最终不得不制作重复记录，更新所有子记录，然后删除原始记录。如果您使用代理主键（通常是自动生成的整数），这比简单地更新 1 条记录的电子邮件地址要难得多

于 2013-11-23T20:16:09.270 回答
0

选择和设计密钥的合理标准是：简单性、熟悉性和稳定性。电子邮件地址对于使用它们的人来说既简单又熟悉，并且相对不经常更改。许多成功的网站和系统都需要唯一的电子邮件地址来识别用户。电子邮件地址是许多用途的完美钥匙。

鉴于电子邮件地址是一个合适的键，问题是它是否应该是主键。主键的选择是在表具有多个键并且您希望出于某种目的选择其中一个作为“首选”时出现的。关于什么应该或不应该成为主键的想法基本上是主观和武断的。没有合理的理论基础可以做出这样的选择，因为指定为主要的键不需要在形式或功能上与任何其他键有任何不同。仅根据人类偏好，电子邮件地址应该比不熟悉且不相关的递增数字做出“更好”的主键选择。

于 2013-11-23T22:47:50.230 回答