例如，像stackoverflow.com这样的网站，使用电子邮件地址识别许多表中的用户是一种好习惯吗？
如果主键很长，那就不好了，比如说
VARCHAR（50）
甚至
VARCHAR（100）
答案 0 :(得分：12)
不是真的。对于任何相当大的数据集，您最终会浪费大量空间，并且在查询时会受到性能影响。此外，如果有人更改了他们的电子邮件（您可能会或可能不允许），您必须在任何地方更改它。
唯一标识用户的代理键将是更好的选择。
答案 1 :(得分：7)
没有。首先，如果同一个用户提出两个问题该怎么办？如果电子邮件是主键，我们现在就违反了PK。
其次，它甚至不应该是复合键的一部分。如果用户更改其电子邮件地址怎么办？然后，您需要在表中进行一系列丑陋的更改。
第三，你应该使用类似自动递增ID的东西。字符串（如电子邮件地址）的效率非常低。
如果您需要将问题与特定成员联系起来，请将memberID外键放入member表中。 answers表应该有自己的自动递增ID，questionID外键到question表，memberID外键到member表，代表提供的成员答案。等
顺便说一下，您可能想要了解database normalization，至少最多third normal form（3NF）。这不是wankery，这只是一个很好的常识。
答案 2 :(得分：4)
除了您不希望字符串作为表格中的主键的所有性能原因之外，还有一些非常具体的原因可以解释为什么不应将电子邮件用作主键：
主键必须是唯一的。但是，规范化电子邮件地址很难。您可能在执行唯一性方面遇到很多问题。 （电子邮件地址是否区分大小写？您是否忽略。或+内部电子邮件？您如何比较非英语电子邮件？）
电子邮件是个人身份信息。将其用于任何目的可能是安全和隐私问题。特别是如果您的一些用户不满13岁。
电子邮件不是永久性的，因为不应该用作身份代表（Should I use a number or an email id to identify a user on website?）。因此，如果用户更改了他们的电子邮件，您必须a）更新所有表的主键，或者b）将旧电子邮件维护为一个键，这使得使用电子邮件作为关键无用的开始。 / p>
答案 3 :(得分：0)
Jay Pipes关于比较主键的int和char之间差异的post可能有助于理解为什么应该使用整数。
答案 4 :(得分：0)
不，这是一个坏主意。电子邮件发生变化，字符串比较相对昂贵。
答案 5 :(得分：0)
代理键是最好的。自然键是教科书。自然键在我看过它们的每个系统上都会造成严重的问题。甚至国民身份证号码也不够独特。
如果您的列已正确索引，大多数现代数据库（Oracle，Postgres，SQLServer）都不会因为加入电子邮件地址而过度惩罚您。如果您担心连接，请创建非规范化的物化视图并在插入/更新时付出代价。