這是一個很好的練習來創建一個大的桌子嗎？

我正在一家企業實習，在SQL數據庫上進行選擇查詢，並且我想退一步確定什麼是一種好的做法，或者不保持這種做法。這是一個很好的練習來創建一個大的桌子嗎？

他們做了一個表，不同類型的代碼，如：

ID  | TYPE  | Code  | 
------------------------------------- 
1  | 1   | red  | 
2  | 1   | white  | 
3  | 1   | blue  | 
4  | 1   | green  | 
5  | 2   | dept1  | 
6  | 2   | dept2  | 
7  | 2   | dept3  | 
8  | 3   | prodtype1 | 
9  | 3   | prodtype2 | 
10  | 3   | prodtype3 |

正如你看到的，對於每個代碼的一些信息。這是一種有效的做法，重新組合一個大表中只有少量信息的表，並在通過列「type」上的WHERE子句選擇時檢索我們的信息？在我的規模上，我將不得不創建三個表格（顏色，部門，生產類型），但是很少有信息。保留三張小桌子是否耗費大量資源？它是否會導致長期存在的巨大問題，使用一張包含不同「種類」信息的大表格？

來源

2017-08-09 Exomus

它們似乎是簡單的文本查找。爲每個查詢分開的表格有優點和缺點。沒有明確的「最佳」選擇。 – Richard

你能列舉這種做法的一些優點和缺點嗎？因爲我發現保留單獨的表格更清晰，但是它也會使關係模型變得沉重，沒有任何好處。 – Exomus

這種（反）模式通常被稱爲OTLT（一個真正的查找表）。國際海事組織的主要缺點是，除非你使用更廣泛的外鍵約束，否則沒有什麼可以阻止某人存儲例如'prodtype2'，a.k.a'9'列在期待顏色的列中。即爲了獲得體面的完整性，FK必須覆蓋'type'列和'id'。 –

我們使用鍵/值表和多個表。這取決於你需要什麼。

例如，您有一個「dept1」。你想保存更多關於你的部門的信息嗎？然後創建一個新表「Department」與它的位置併爲這個新表創建一個外鍵是有意義的。

至於性能，只要您的索引是正確的，兩者都應該可以正常工作。

來源

2017-08-09 08:03:37 Carra

表中的信息僅用於在某些報告上進行打印，並且沒有關於每個代碼的更多信息。 – Exomus

如前所述，這是一種通常被認爲是反模式的實體屬性值模式。可以在https://www.red-gate.com/simple-talk/blogs/when-the-fever-is-over-and-ones-work-is-done/

一個真正的查找設計完全或者不增加巨大的複雜性實施參照完整性時遇到麻煩。

設計表示數據庫內的數據庫，有時稱爲內部系統效果。

有一些特定和有限的使用情況或EAV模型有用的情況。這些往往是在一個實體的屬性可以非常自由的形式。

大量的數據類，它們的屬性幾乎沒有共同之處。
每個對象有少量屬性。
流動的業務需求或困難的數據需求使傳統的數據建模變得困難或不切實際。
實體內的變化率很低，僅限於插入和刪除。
與模型中對象的交互主要在實體級別，即整個實體被檢索到，很少（如果在屬性級別執行任何過濾）。

系統中它的工作原理是

調查和問卷
產品評價系統
應用程序配置系統
醫療系統

這些天我會質疑是否RDBMS是這些用例的正確解決方案唉。 NOSQL解決方案（如文檔存儲）與上述用例更接近。

來源

2017-08-09 10:32:36

這是一個很好的練習來創建一個大的桌子嗎？

回答

相關問題