關於關係數據庫中的查找表的最佳實踐是什麼？
查找表（或程式碼表，有些人稱之為）通常是可以為特定列給出的可能值的集合。
例如，假設我們有一個名為
party（用於儲存有關政黨的資訊）的查找表，它有兩列：
party_code_idn，它保存系統生成的數值，並且（缺乏業務領域含義）用作真實鍵的代理。party_code, 是表的真實或“自然”鍵，因為它維護具有業務領域內涵的值。讓我們說這樣的表保留了以下數據：
+----------------+------------+ | party_code_idn | party_code | +----------------+------------+ | 1 | Republican | | 2 | Democratic | +----------------+------------+保留值“Republican”和“Democratic”的
party_code列是表的真正鍵，設置了一個 UNIQUE 約束，但我可以選擇添加party_code_idn並將其定義為表的 PK（儘管從邏輯上講,party_code可以作為 PRIMARY KEY$$ PK $$). 題
從事務表中指向查找值的最佳實踐是什麼？我應該建立外鍵（FK）引用**（a）直接指向自然和有意義的值還是（b）**替代值？
選項（a），例如，
+---------------+------------+---------+ | candidate_idn | party_code | city | +---------------+------------+---------+ | 1 | Democratic | Alaska | | 2 | Republican | Memphis | +---------------+------------+---------+具有以下屬性1：
- 最終使用者可讀 (+)
- 易於跨系統導入導出(+)
- 很難更改值，因為它需要在所有引用表中進行修改 (-)
- 添加新價值並不昂貴（=）
我認為這幾乎就像“按值傳遞”，以應用程序程式術語中的函式呼叫進行類比。
選項 (b)，例如，
+---------------+----------------+---------+ | candidate_idn | party_code_idn | city | +---------------+----------------+---------+ | 1 | 1 | Alaska | | 2 | 2 | Memphis | +---------------+----------------+---------+具有以下屬性：
- 最終使用者不可讀 (-)
- 難以導入導出，因為我們需要取消引用它 (-)
- 易於更改值，因為我們僅將引用儲存在事務表中(+)
- 添加新價值並不昂貴（=）
如果與應用程序程式用語中的*函式呼叫相比，它與“*通過引用傳遞”非常相似。
導入-導出也可以以不同的方式完成，即，只需再次填充查找表，然後重新播種代理列。我希望我做對了，這是我剛剛聽說的一種可能性。
1. 注意
+,-並=指出這些屬性的好處。題
非常重要的是：如果我們只使用後一種方法，查找（或程式碼）表和 FK 引用之間是否有區別？我認為它們的工作方式相同。
相關資源
，
IDN我認為你的意思是一個IDENTITY，SEQUENCE或AUTO_INCREMENT領域？你應該看看這里和這裡。請注意，第 5 節（將數據值用作數據元素）第一個參考，在圖 10 下方
當然，您可以為銷售人員創建一個單獨的表，然後使用外鍵引用它，最好使用簡單的代理鍵，例如 sales_person_id ，如上所示。
所以，這位專家認為你應該“尊重”代理鍵。這確實是一種非常基本的 SQL 技術，不會在您的日常 SQL 中引起問題。圖 10 中似乎存在錯誤 - SalesData 中的 sales_person 應該是代理鍵（即數字），而不是文本。我從上面的引用中推斷出這一點。
您應該不惜一切代價避免犯下第 (1) 通用查找表中概述的錯誤的誘惑（對於新手數據庫程序員來說非常常見）。這通常被稱為 MUCK（大規模統一程式碼密鑰）方法（並非偶然:-)，尤其是Joe Celko，也諷刺地稱為 OTLT -一個真正的查找表）並導致各種困難。新手程序員似乎覺得單個程式碼/查找/任何表“更乾淨”，並且當沒有什麼比事實更進一步時效率更高。
從上面的第二個參考：
規範化消除了冗餘數據，從而大大簡化了執行數據完整性的任務，但是創建 MUCK 的過程完全是另一回事。MUCK 不會消除冗餘數據，而是消除了被認為是冗餘表的內容，但是正如我將展示的，更少的表格並不等於簡單。