創建一個“Id”列是否值得？

我有一個表，它有一列Name，它的類型是VARCHAR2(20)唯一的，不能為空，也不能更改。

起初我用它作為這個表的主鍵，但我想知道是否最好創建另一個列Id（當然命名更合適）並處理與它的表關係。

我知道擁有一Id列是一種常見的最佳實踐，但我聽說Id要避免將數據庫與大量無意義的列聚集在一起（Name列具有更多的語義）。

在這種情況下，您有什麼建議？

由於名稱是唯一的並且永遠不會改變，因此從關係理論的角度來看，它肯定是一個很好的候選鍵。

由於空間和性能原因，您可能會發現使用整數代理鍵更可取，因為它比每個具有該表的外鍵的表中的文本佔用的空間更少（並且作為 FK 的每個索引通常都是索引列）。對整數列進行搜尋/連接的操作也會更快，但對於在此表中連接並需要輸出和/或按名稱排序的查詢，您可能會發現從 id 到 name 的額外工作會消除一些好處。當然，空間和性能差異可能不足以對您的項目產生影響，這取決於偏好。

事實上，我懷疑即使使用 UUID 也可能比使用名稱更快，假設您的 DBMS 具有正確的 UUID 類型，因此它們以緊湊的二進制形式而不是文本欄位儲存，儘管該類型的固定 16 字節長度可能比平均長度長您的名稱值的長度，因為與固定長度二進制值的比較比可變長度字元串之間的比較快（對此進行基準測試並查看差異是否確實顯著會很有趣） - 儘管除非您有理由使用 UUID（複製問題等）較小的整數類型當然會更有效並且佔用四分之一的空間。

**tl; dr：**所描述的名稱列是一個非常好的候選鍵，實際上在理論上是完美的，但實際上整數代理鍵將更多空間和處理效率。

引用自：https://dba.stackexchange.com/questions/54570