關於關係數據庫中的查找表的最佳實踐是什麼?
查找表(或程式碼表,有些人稱之為)通常是可以為特定列給出的可能值的集合。
例如,假設我們有一個名為
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 不會消除冗餘數據,而是消除了被認為是冗餘表的內容,但是正如我將展示的,更少的表格並不等於簡單。