0

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

方法 1：多个表，每个表建模一个实体

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

要查询，我需要UNION ALL对所有表执行 a 。

方法 2：包含所有列和类型列的单个表

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

在这里，我可以直接查询列。

问题是该UNION ALL方法是否存在任何性能问题？这个问题类似于之前在 PostsgreSQL 上提出的问题，但尚未得到回答。

编辑：

感谢您的所有回答。

实体表是日期索引的。并且查询大部分是过滤的时间日期或过滤的共享字段。假设 C1 是日期，C2 是字符串，95% 的查询看起来像 C1>=from 和 C1<=to，或 C2='SomeId'。

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

4

3 回答 3

2

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

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

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

如果公共列和类型很可能通常由它们自己查询（类型 a 和类型 B 通常不会同时出现在最频繁运行的查询类型的结果集中），那么用一个视图分隔表UNION all 几次，您需要查询所有这些都将起作用。

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

于 2013-08-06T17:16:12.570 回答
1

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

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

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

于 2013-08-06T17:18:15.623 回答
0

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

All - ID, Type, C1, C2

以及三个“后代”表，IDPK 在哪里，同时它是ID表的 FK All：

Entity1 - ID, C3
Entity2 - ID, C4
Entity3 - ID, C5
于 2013-08-06T19:20:54.273 回答