SQL Server：UNION ALL vs 将所有列聚合到一张表中答案

【问题标题】：SQL Server: UNION ALL vs Aggregate all columns into one tableSQL Server：UNION ALL vs 将所有列聚合到一张表中
【发布时间】：2013-08-07 03:53:49
【问题描述】：

我对两种设计的性能有疑问。目标是存储多种类型的实体，它们共享一些属性但也不同。

方法 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

记录数量增长缓慢，每个实体每天可能有几百条记录。列数不会超过 150。但是，共享列的数量很少。目前我已经实现了方法 1，因为每个实体都可以使用共享以外的字段作为主键。这样约束更自然。

【问题讨论】：

您可能需要考虑 eva 模式。 en.wikipedia.org/wiki/…
根据我的经验，Union 查询比较慢，所以一般来说单表应该比较快。你打算做很多类型特定的过程吗？他们实际共享了多少数据？如果把它们放在一起，会不会有尺寸问题？
@Declan_K，EAV 模式是最糟糕的。除非您绝对无法事先定义您需要哪些文件，否则应避免使用它们。这两种方法都应该比 EAv 方法执行得更好，并且更容易查询。

标签： sql sql-server tsql

【解决方案1】：

在做出此选择时，很大程度上取决于表需要多宽、是否有任何共享列、表有多大、您将对表执行什么样的查询等。

根据经验，如果表格宽度接近数据库支持记录的最大宽度，则不要放入一个表格中。不太宽的表往往表现更好。如果您谈论的专栏很少，这可能是最好的解决方案。

如果公用列是最常查询的列，则考虑设计一个包含公用列的父表和三个用于特定类型列的子表。

如果公共列非常少，并且类型很可能通常会被自己查询（类型 a 和类型 B 通常不会同时出现在最频繁运行的查询类型的结果集中），则使用 a 分隔表如果您需要查询所有这些 UNION 几次，则视图将起作用。

如果您只需要查询所有类型的报告而不是所有普通的日常资料，请考虑使用单独的表和数据仓库来进行报告。

【讨论】：

【解决方案2】：

您打算大概有多少行？我有使用像这样的大表的经验，他们采用单表方法，除非您点击其中一个索引（表大约 250 列乘近 10 亿行），否则获取任何数据的速度非常慢。

由于列的数量，为每个常见的过滤条件建立索引是不切实际的，因为这会大大减慢事务系统上的插入速度。如果表是分开的，那么这个例子肯定会容易得多，而且我们可能有一个视图将它们放在一起，以应对我们必须一起查询所有数据的情况。

但是，我意识到有很多变量需要考虑。如果您正在使用主要用于 OLAP 而不是 OLTP 的数据库，那么您可能不会担心添加大量索引。

【讨论】：

【解决方案3】：

作为替代方案，您可以结合方法 1 和 2，即您可以创建“祖先”表：

All - ID, Type, C1, C2

还有三个“后代”表，其中ID 是PK，同时它是ID 的All 表的FK：

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

【讨论】：