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

Question

我的Web应用程序将有各种类型的用户：root用户，系统管理员，客户，承包商等。我想要一个表格“用户”，其中将有“用户名”，“密码”，和角色是上述角色之一的“角色”。例如，我会为了存储客户特定的属性而拥有一个名为“客户”的表格。

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

感谢您的回复。

Answer 1

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

Answer 2

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

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

Answer 3

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

概括地说，没有什么是切割和干燥，就需要相互竞争的利益之间进行平衡：

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

在用户名的情况下...

1. 你可能会想允许更新。
2. 这是不可能的，你需要查找只有的用户名。
3. 对用户名进行范围扫描没有任何意义（与equi-searching不同）。
4. 你没有储存地球的全部人口，是吗？
5. 我们在这里谈论的是“独立”的自然钥匙，而不是一个确定关系结果的自然钥匙。
6. 未知？

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