情况：我们有一个大型数据库，其中包含许多非规范化表。我们经常不得不重新汇总数据以使汇总表保持同步。我们讨论过如何使用计算列来保持数据新鲜。我们还讨论了触发器，但这是一个单独的讨论。

在摘要表中，我们对表进行了规范化，以便将标准ID和标准说明存储在表中。本质上是假定该表将被足够频繁地重新汇总，以便如果他们更改标准描述，它也将在摘要表中对其进行更改。
一个错误的假设。

问题：
如果我们将汇总表中的标准说明设为从标准表中选择标准说明的派生/计算列，该怎么办？
通过在具有100,000-500,000行的表上删除计算列是否会对性能产生巨大的影响？

解决方案

这不是一个真正的答案，但是使用视图有什么问题呢？

当计算列不占用大量计算并且不对大量行执行时，它们是很好的选择。问题是"删除计算所得的列是否会造成打击"。除非此列是查询所用的索引(对组合列建立索引的好主意，我不知道是否可以依赖数据库)，否则删除它不会影响性能(减少查询和处理数据的次数) 。

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

我们暗示了什么可能是真正的问题，那就是数据库的架构。以前，我曾遇到过类似的问题，其中的系统是为处理一件事情而构建的，而诸如报告之类的东西则需要安装/插入。在不重构架构以平衡所有需求的情况下，Sunny使用视图的想法只是唯一的简便方法。

如果我们要发布一些清理过的DDL和数据，并举例说明我们尝试从数据库中获取的内容，我们可能会给我们一个不太主观的答案。

表中的计算列只能从该行的值派生。我们无法在计算列中进行查找。为此，我们将需要一个视图。

在一个表上，将名称小的正常化到表中可能会对性能造成的影响可忽略不计。我们可以使用DBCC PINTABLE来提示服务器将表保留在缓存中。

如果我们需要实时进行更新，那么唯一的选择就是触发器。在与要更新的名称相对应的ID列上放置聚簇索引将减少总体I / O数量(给定ID的记录将在同一块或者一组块中)，因此，如果触发器引起了，请尝试执行此操作性能问题。

只是为了阐明sql2005及更高版本的问题：

This functionality was introduced for
  performance in SQL Server version 6.5.
  DBCC PINTABLE has highly unwanted
  side-effects. These include the
  potential to damage the buffer pool.
  DBCC PINTABLE is not required and has
  been removed to prevent additional
  problems. The syntax for this command
  still works but does not affect the
  server.