SQL Server：UNION ALL vs將所有列合併到一個表中

Question

我對兩個設計的性能有疑問。目標是存儲多種類型的實體，他們共享一些屬性，但也有所不同。

方法1：多個表，每個建模一個實體

Entity1 - C1, C2, C3 
Entity2 - C1, C2, C4 
Entity3 - C1, C2, C5  

要查詢，我需要對所有表執行UNION ALL。

方法2：單表中的所有列和類型列

All - Type, C1, C2, C3, C4, C5 

在這裏，我可以列上直接查詢。

問題是UNION ALL方法是否有任何性能問題？這個問題與PostsgreSQL上的previously asked question類似，但尚未得到解答。

編輯：

謝謝你的所有答案。

實體表爲日期索引。查詢大部分時間都是日期過濾的，或者過濾了共享字段。假設C1是一個日期，C2是一個字符串，95％的查詢看起來像C1> = from和C1 < = to或C2 ='SomeId'。

記錄數增長緩慢，可能每個實體每天幾百個。列數不會超過150.但是，共享列數很少。目前我已經實現了方法1，因爲每個實體都可以使用除共享之外的字段作爲主鍵。這樣的約束更自然。

Answer 1

在做出這個選擇時，它很大程度上取決於表格的寬度，如果有共享的列，表格的大小，表格的類型，您將針對表格執行哪種查詢等。

作爲一個經驗法則，如果表格寬度將接近數據庫支持記錄的最大寬度，則不要放在一個表中。不太寬的桌子往往表現更好。如果你談論的專欄很少，這可能是最好的解決方案。

如果公共列將是最常被查詢的列，那麼考慮設計一個具有公共列和三個子類表的父類表格以用於特定類型的列表。

如果只有很少的公共列和類型通常很可能會被自己查詢（類型a和類型B通常不會在最頻繁運行的查詢類型的結果集中），那麼將表一個查看所有這些都需要查詢所有這些數據的工作。

如果您只需要查詢所有類型的報表，但不是所有普通的日常事務，則可以考慮將單獨的表格和數據倉庫用於報表。

Answer 2

您計劃大概有多少行？我有使用這樣一個大表的經驗，他們去了單表的方法，並且除非你點擊其中一個索引（表格大約250列，近10億行），否則返回數據的速度非常慢。

由於列數太多，建立每個常用過濾標準的索引是不現實的，因爲這會減慢在事務系統上的相當大的插入。如果表格是分開的，那麼這個例子當然會容易得多，而且我們也許有一種觀點，當我們必須將所有數據一起查詢時，將它們放在一起。

但是，我很想知道有很多變數需要考慮。如果您正在使用主要用於OLAP而不是OLTP的數據庫，那麼您可能沒有任何關於添加大量索引的問題。

Answer 3

作爲替代方案，你可以結合方法1和2，也就是說，用戶可以創建「祖先」表：

All - ID, Type, C1, C2 

三和「後裔」表，其中ID是PK，並在同一時間，它是FK到ID of All表格：

Entity1 - ID, C3 
Entity2 - ID, C4 
Entity3 - ID, C5