即使用戶名是唯一的，也要創建用戶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. 未知？

...所以在這種情況下代理鍵可能是合理的。