最佳實踐：數據庫引用表

在數據庫設計中，對於小塊數據，元組vs引用表有什麼感受？最佳實踐：數據庫引用表

例如，假設您正在設計涉及辦公室管理的模式。你想記錄每個員工屬於哪個部門，但是對任何有關部門的信息不感興趣。因此，你的EMPLOYEE表中有部門作爲字符串/ char/varchar/etc，還是將它作爲外鍵，與DEPARTMENT表相關聯。

如果DEPARTMENT表只記錄部門名稱以外的任何內容，通常需要將其與EMPLOYEE表結合使用。但是，如果這包含在EMPLOYEE表中，則不能保證某些用戶將呼叫人力資源「人力資源」，有些人可能將其稱爲「人力資源」，有些人可能稱之爲「人力資源」等。將其作爲外鍵保證它只能是一件事。另外，如果有關於部門的其他信息被添加，如果它在自己的表格中，這將是容易的。

那麼人們怎麼想呢？當然，更多的表格和引用也可能會對性能產生負面影響。我的問題具體是在考慮Oracle 11g的情況下提出的，但我懷疑涉及的rdms類型對此設計考慮有多大影響。

來源

2013-05-02 Stumbler

我認爲你回答了你自己的問題：「如果這包含在EMPLOYEE表中，你不能保證有些用戶會打電話給HR'HumanResourses'，有人可能會把它稱爲'H-R'，有人可能稱之爲」人力資源「等等」......你有沒有意識到你現在實際上需要擔心在這一點上的表現？ – 2013-05-02 13:57:09

如果您使用相關表格，那麼因爲人事部門成爲人力資源部門，所以您沒有更新1,000,000條記錄的性能問題。

您有另一種選擇。創建表並將其用作數據輸入的查找。但是將信息存儲在主表中。

但是，我更喜歡爲部門使用相關表並將部門和員工的ID存儲在具有ID和開始和結束的連接表中。隨着時間的推移，員工傾向於從一個部門轉到另一個部門報告能夠分辨出他們在什麼時候是有幫助的。您需要考慮如何在設計這類事物時使用數據和報告。短視的設計很難在以後修復。

您擔心有太多表格是沒有根據的。數據庫被設計爲擁有許多表並使用連接。如果您的索引正確，那麼對大多數數據庫不會有性能影響。而且你知道什麼，我知道很多很多表有很多數據表的數據庫，這些數據表現得很好。

來源

2013-05-02 14:05:08 HLGEM

FWIW，我有一天在我的臺式電腦上測試了級聯更新。它在不到3秒的時間內將更新級聯到5000萬行的300萬行中。（PostgreSQL 9.1。電腦沒什麼特別快或特別的。）我不認爲我多年來一直擔心級聯更新的速度。所以我同意「更多表格」，但不要總是同意「使用ID號碼」。 +1 – 2013-05-02 14:25:20

如果你正在處理真正的海量數據集，那麼你只需要擔心這類事情對性能的影響。對於任何這樣的常規辦公環境系統，更喜歡標準化的模式。

來源

2013-05-02 13:59:19 Rik

最佳實踐：數據庫引用表

回答

相關問題