即使用户名是唯一的，也要创建UserID？

Question

我的网络应用程序将拥有各种类型的用户：root用户，sys-admins，客户，承包商等。我想要一个表“User”，其中包含“Username”，“Password”列和角色是上述角色之一的“角色”。例如，我还会有一个名为“Customer”的表来存储客户特定的属性。

这是我的问题。由于所有用户名都是唯一的，我可以使用用户名作为User表的主键。但是，更有意义的是，创建“用户ID”列并使用它而不是用户名列作为PK吗？还有许多其他表将使用此用户PK作为外键，我认为从性能角度来看，比较用户ID而不是用户名文本字符串会更快。

感谢您的回复。

Answer 1

这是旧的自然与代理关键辩论。

简而言之，没有什么是切割干燥的，你需要在竞争利益之间取得平衡：

1. 如果您预计需要更新密钥，请使用代理（不需要更新）以避免ON UPDATE CASCADE。
2. 如果您需要查找密钥而不是其他列，请使用自然键完全避免JOIN。但是，如果您需要查找的不仅仅是密钥，请使用代理来使FK和附带的索引更加简洁和高效。
3. 您是否预计自然键上的范围扫描？如果是，请cluster。但是，二级索引在群集表中可能很昂贵，而这些索引与代理键相关。
4. 你的桌子很大吗？通过只有一个索引（在自然键上）而不是两个（在自然和代理上）来节省空间。
5. correctly modeling diamond-shaped dependencies可能需要复合自然键（位于识别关系的子端点）。
6. 代理人可能对ORM工具更友好。

对于用户名...

1. 您可能希望允许更新。
2. 您不太可能需要查找仅用户名。
3. 对用户名进行范围扫描毫无意义（与等搜索不同）。
4. 你没有存放地球上的所有人口，是吗？
5. 我们在这里谈论的是“独立”的自然关键，而不是识别关系的结果。
6. 未知<？/ LI>

   ...所以在这种情况下代理密钥可能是合理的。

Answer 2

我会创建userid，因为虽然用户名可能是唯一的，但它们通常不可更改，我宁愿不必更改数千或数百万条记录，因为HLGEM想要成为HLGEM_1。进一步加入整数更快。

Answer 3

有两种思想流派。数据库纯粹主义者认为，你应该尽可能使用自然键（这是有意义的）。因此，如果您订阅了这一思路，并且用户名不可更改，则将密钥设为用户名。

数据库实用主义者认为代理键更有用，并且更倾向于更好地适应需求的变化。在某些情况下，它们也可以更快，特别是对于大字符串键。还存在安全问题，因为使用自然键可能会泄漏代理键无法获得的信息。