使用电子邮件地址作为主键的做法是什么？我应该避免使用自动递增的ID号，还是引擎能够处理它？</ p>
MySQL数据库，但我对其他引擎如何处理这个问题很感兴趣（特别是PostgreSQL）。
答案 0 :(得分：8)
您应始终拥有唯一的无商业价值的整数主键。然后将其称为代理键。
您应该将电子邮件地址本身存储在另一个字段中，通常使用索引，以便它可以作为查找的键。
这将使您能够提供基于使用查找的电子邮件地址定位用户的功能。此时的任何其他功能然后将该记录主键用于其他操作，例如，更新用户地址。
答案 1 :(得分：4)
仅在符合相当狭窄的标准的情况下使用电子邮件地址是完全合理的：
换句话说，很少适合使用电子邮件地址作为主键。我能真正想到的唯一情况是处理邮件流的软件，它想要记录每个电子邮件地址的统计信息。
如果您打算将其用作用户的标识符，不要这样做。
您没有使用电子邮件地址来识别其他内容，例如用户帐户，而是使用所有关于电子邮件地址的表格。比如说，您正在跟踪每个地址传入/传出的消息数量。如果您使用电子邮件地址识别其他内容，则不将其用作主键。如果没有完全稳定的小而简单的自然键，请使用代理键。姓名和电子邮件地址发生变化。
对于具有电子邮件地址作为主键的表，没有太多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。
答案 2 :(得分：1)
使用自动递增的主键。您不需要向用户公开此信息，您可以直观地表示它，就像密钥是电子邮件地址一样，但是您需要内部一致且不随时间更改的数字。
请记住，您的主键用于链接到其他表，因此如果有人更改了他们的电子邮件地址，您还必须更新所有相关链接。这很难做到。
使用什么SQL数据库并不重要，它们的工作方式大致相同，并且具有类似的限制。
答案 3 :(得分：0)
不使用业务信息作为主键而是使用代理主键的一个重要原因是外键。想象一下，某人的电子邮件地址需要更新。你能想象更新密钥中的所有信息会带来多大的痛苦吗？如果您的外键足够严格，您可能需要制作重复记录，更新所有子记录，然后删除原始记录。如果您使用代理主键（通常是自动生成的整数），那么仅仅更新1个记录电子邮件地址要困难得多
答案 4 :(得分：0)
选择和设计密钥的合理标准是：简单，熟悉和稳定。电子邮件地址对于使用它们的人来说很简单和熟悉，而且它们的变化相对较少。许多成功的网站和系统需要唯一的电子邮件地址来识别用户电子邮件地址可以用于许多目的。
鉴于电子邮件地址是合适的密钥，问题应该是主密钥。当一个表具有多个键并且您希望为某些目的选择其中一个作为“首选”时，会出现主键的选择。关于应该或不应该成为主键的想法从根本上是主观的和随意的。没有合理的理论依据可以做出这样的选择，因为指定为主要的密钥不需要在形式或功能上与任何其他密钥有任何不同。仅基于人的偏好，电子邮件地址应该比不熟悉和不相关的递增数字做出“更好”的主键选择。