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

Question

我的Web应用程序将有各种类型的用户:root用户,sys-admins,客户,承包商等.我想要一个表"User",其中包含"Username","Password"和"角色"角色是上述角色之一.例如,我还会有一个名为"Customer"的表来存储客户特定的属性.

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

感谢您的答复.

Answer 1

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

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

1. 如果您预计需要更新密钥,请使用代理(不需要更新)以避免ON UPDATE CASCADE.
2. 如果需要查找键,而不是其他列,请使用自然键完全避免JOIN.但是,如果您需要查找的不仅仅是密钥,请使用代理来使FK和附带的索引更加简洁和高效.
3. 您是否预期自然键上的范围扫描？如果是,请将其群集.但是,二级索引在群集表中可能很昂贵,而这些表对着代理键.
4. 你的桌子很大吗？通过只有一个索引(在自然键上)而不是两个(在自然和代理上)来节省空间.
5. 复合自然键(位于识别关系的子端点)可能是正确建模菱形依赖关系所必需的.
6. 代理人可能对ORM工具更友好.

在用户名的情况下......

1. 您可能希望允许更新.
2. 您不太可能只需要查找用户名.
3. 对用户名进行范围扫描毫无意义(与等搜索不同).
4. 你不是在储存整个地球的人口,不是吗？
5. 我们在这里谈论的是"独立"的自然关键,而不是识别关系的结果的自然关键.
6. 未知？

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

Answer 2

我会创建用户 ID，因为虽然用户名可能是唯一的，但它们通常不是不可更改的，而且我不想更改数千或数百万条记录，因为 HLGEM 希望成为 HLGEM_1。对整数的进一步连接速度更快。