1

The situation: we have a large database with a number of denormalized tables. We frequently have to resummarize the data to keep the summary tables in synch. We've talked on and off about using computed columns to keep the data fresh. We've also talked about triggers, but that's a separate discussion.

In our summary tables, we denormalized the table such that the Standard ID as well as the Standard Description is stored in the table. This inherently assumes that the table will be resummarized often enough so that if they change the standard description, it will also change it in the summary table. A bad assumption.

Question: What if we made the Standard Description in the summary table a derived/computed column which selects the standard description from the standard table? Is there a tremendous performance hit by dropping a computed column on a table with 100,000-500,000 rows?

4

3 回答 3

1

表中的计算列只能从该行上的值派生。您不能在计算列中进行查找。为此，您需要一个视图。

在一个表上，将名称非规范化到表中可能对性能的影响可以忽略不计。您可以使用DBCC PINTABLE来提示服务器将表保留在缓存中。

如果您需要实时更新，那么您唯一的选择就是触发器。将聚集索引放在与您正在更新的名称相对应的 ID 列上应该会减少总体 I/O 量（给定 ID 的记录将位于同一块或一组块中）因此，如果触发器导致，请尝试此操作性能问题。

于 2008-09-24T08:54:11.393 回答
1

当计算列不是计算密集型并且不在大量行上执行时，它们很好。您的问题是“删除计算列是否会有影响”。除非此列是查询使用的索引（索引一个比较列真的很糟糕 - 我不知道您是否可以取决于您的数据库），否则删除它不会损害您的性能（查询和处理的数据更少）。

如果标准表有描述，那么你应该从 id 加入它，而不是使用任何计算。

您提到了可能是一个真正的问题，那就是您的数据库的架构。我以前也遇到过这样的问题，系统是为处理一件事而构建的，而报告之类的东西需要被固定在上面。在不重构架构以平衡所有需求的情况下，Sunny 使用视图的想法几乎是唯一简单的方法。

如果您想发布一些经过清理的 DDL 和数据，以及您试图从数据库中获取的内容的示例，我们可能会给您一个不那么主观的答案。

于 2008-09-22T19:56:42.270 回答
0

只是为了澄清 sql2005 及更高版本的问题：

在 SQL Server 6.5 版中引入了此功能以提高性能。DBCC PINTABLE 具有非常有害的副作用。这些包括损坏缓冲池的可能性。DBCC PINTABLE 不是必需的，已将其删除以防止出现其他问题。此命令的语法仍然有效，但不影响服务器。

于 2008-10-02T08:54:50.940 回答