具有相同列的相同表的數據建模

我有很多具有相同列數和名稱的表，因爲它們都是查找表。例如，有LabelType和TaskType表。 LabelType和TaskType表具有TypeID和TypeName列。它們將用作其他表中的外鍵，如具有shippingLog表的LabelType表和具有EmployeeTask表的TaskType表。具有相同列的相同表的數據建模

LabelType Table 
TypeID TypeName 
1  Fedex 
2  UPS 
3  USPS 

TaskType Table 
TypeID TypeName 
1  Receiving 
2  Pickup 
3  Shipping

到目前爲止，我有超過20張桌子，我期待着它會不斷增加。我沒有問題，但我只是想知道是否有更好或更聰明的方式使用表或不。我甚至想將所有這些表合併爲一個查找類型表，並通過在查找表中添加一個外鍵來區分它們。查找表可能包含標籤，任務等數據。然後，我只需要一個或兩個表來查找所有這些查找數據。

請告訴我，如果你有任何更好或更聰明的數據建模方式。

來源

2012-08-24 Hoorayo

僅僅因爲數據具有相似的結構並不意味着它具有相同的含義或相同的約束。保持查找表分開。這使外鍵分開，因此數據庫可以防止引用錯誤的查找數據。

我希望關係DBMS支持繼承，您可以在父表中定義基本結構並在子表中添加特定的FK。現在，您需要忍受DDL中的一些重複...

注意：「保持查找表單獨」規則的一個例外可能是您的系統需要動態（即能夠添加新的查找數據類型，而無需在數據庫中真正創建新的物理表），但它並不適合您的問題。

有了一個大的查找表，FKS不會單獨從引用意味着爲EmployeeTask表中的行停止（比如說）ShippingLog表。通過使用識別關係和遷移PK，您可以保護自己免受這種影響，但不是沒有引入冗餘並需要一些謹慎的限制。它更乾淨，可能更高性能，只需做正確的事情，並保持查找表分開。

來源

2012-08-25 19:01:50

感謝您的明確答案。創建表格一點也不麻煩。我只是想知道在數據庫上創建表和關係的最有效和正確的方法。 – Hoorayo

我與我的同事喜歡爭論所有類別的一張表，因爲它可以方便地編寫爲.Net開發人員。但我在桌子之間的完整性方面與他不同意。我同意編碼方便，因爲我是.Net開發人員，因爲使用一個表格可以更容易地製作各種類型的下拉框，例如在用戶界面上顯示Label類型，Shipping類型等。但我想我可以使用動態SQL存儲過程來實現這一點。 – Hoorayo

@Hoorayo如果出於某種原因使客戶端的事情變得更容易，您可以通過VIEW來始終「重新合併」查找表。你甚至可以使用'Kind'字段來指示哪個表中的任何特定行來自哪個表，因此您可以使用單個參數化查詢來獲取任何表。有關工作示例，請參閱此[SQL小提琴]（http://sqlfiddle.com/#!3/fa42b/2）。 –

保持查找表分開。查找時間更快，當您添加新的查找表時，您將在數次之間執行數百萬次查詢。

很多表並不是一個大問題。

來源

2012-08-24 23:49:15

爲什麼大量表格比單個正確索引和正確鍵表更有效？如果我們真的在談論數以百萬計的查詢，那麼物理上將它們分開但不是邏輯上的（例如分區）更易於管理和編碼（噸的類似表似乎適用於大量的動態SQL）。 –

如果pair 1 - Receiving和pair 1 - Fedex存儲在不同的行中，則必須添加第三列以在查找時消除歧義。第三列將使查找速度變慢。如果兩個對存儲在同一行中，則需要兩個單獨的列來存儲Fedex和Receiving in。這會降低速度，涉及比許多表更多的手動管理。 –

如果第三列被編入索引，查找速度不應該比較慢。另外，參數化列值比表名更好。隨着您的建議，代碼必須在每次添加新查找時進行更改。我認爲你根本沒有在這裏提出強有力的案例，特別是從管理角度來看。在現有表格中插入新行涉及比添加新表格和更改代碼更多的手動管理？ –

具有相同列的相同表的數據建模

回答

相關問題