0

我曾多次遇到以下困境，很想听听其他人是如何解决这个问题的，或者是否有一种可以解决这种情况的规范方法。

在某些领域，人们自然会考虑非常宽的表。以多年来发展的时间序列调查为例。这样的调查可能有数百甚至数千个变量。通常虽然可能只有几千或几万行。将这样的结果集视为一个表是绝对自然的，其中每个变量对应于表中的一列，但是，至少在 SQL Server 中，一个被限制为 1024（非稀疏）列。

明显的解决方法是

  1. 将每条记录分布在多个表上
  2. 将数据填充到单个表中，其中包含 、ResponseId、VariableName、ResponseValue

第 2 号。我认为由于多种原因（难以查询、次优存储等）非常糟糕，所以第一选择是我看到的唯一可行的选择。或许可以通过将可能一起查询的列分组到同一个表中来改进这种选择——但在实际使用数据库之前，人们无法真正知道这一点。

所以，我的基本问题是：有没有更好的方法来处理这种情况？

4

3 回答 3

1

嗯，这真的取决于你用它做什么。如果您想保持表尽可能宽（可能是用于 OLAP 或数据仓库），我会使用适当的索引。同样基于更频繁地选择的列，我还可以使用覆盖索引。根据搜索频率更高的行，我还可以使用过滤索引。如果表中有数十亿条记录，您也可以对表进行分区。

如果您只想将表存储在多个表上，请务必使用适当的规范化技术，可能高达 3NF 或 3.5NF，将大表划分为较小的表。我会使用你的第一种方法，规范化，来存储大表的数据，只是因为这样对我来说似乎更有意义。

于 2012-07-10T22:47:49.533 回答
1

您可能希望在表格前面放置一个视图，以使它们看起来好像是一个单独的表格。好处是您可以稍后重新排列存储，而无需更改查询。缺点是只能通过视图对基表进行修改。如有必要，您可以使用存储过程来缓解这种情况，以进行经常使用的修改。根据您的时间序列调查用例，听起来插入和选择比更新或删除要频繁得多，因此如果您以后需要重新安排事情，这可能是保持灵活性而不强迫客户更新的可行方法。

于 2012-07-10T22:50:59.927 回答
0

这是一个古老的话题，但我们目前正在努力解决。上述答案都没有真正提供与我们认为已经找到的解决方案一样多的好处。

我们以前认为拥有宽表并不是真正的问题。在花时间分析这一点后，我们已经看到了曙光，并意识到插入/更新的成本确实已经失控。

正如上面 John 所说，解决方案实际上是创建一个 VIEW 来为您的应用程序提供一致的模式。在我们的案例中，任何重新设计的挑战之一可能是，您有成千上万行代码引用旧的宽表，并且您可能希望提供向后兼容性。

视图也可以用于 UPDATES 和 INSERTS 正如 John 所暗示的那样，但是我们最初发现的一个问题是，如果您以myWideTable可能有数百列的示例为例，并且您希望将其拆分为与myWideTable_acolumns和and with columns a，以及然后插入到仅设置列的视图将仅插入一条记录bcmyWideTable_bxyzamyWideTable_a

当您想稍后更新您的记录并设置时，这会导致问题，myWideTable.z因为这将失败。

我们采用的解决方案和性能测试是在视图插入上有一个“insteadof”触发器，以始终插入到我们的拆分表中，这样我们就可以继续更新或从视图中读取而不受惩罚。

关于在插入上使用此触发器是否会比宽表提供更多开销的问题仍然悬而未决，但很明显它将改善对每个拆分表中列的后续写入。

于 2014-04-10T12:55:46.410 回答