データベースビューを使用するシステムがあります。これは、いくつかの参照テーブル（ルックアップ）からデータを取り出し、固定および静的）の場所に移動し、データのビュービューをアプリケーションに戻します。生成された正規化されていないビューテーブル
新しい要件が追加されているため、このビューは低速になりつつあります。
通常の表を作成し、ビューからこの表に選択し、その索引付けされた高速表を使用して問合せを行うことが、解決策です。
問題は、基本となるテーブルが変更された場合、新しいテーブルに古い結果が表示されることです。しかし、この表を駆動するデータは非常に頻繁に変化しません。そしてもしそうであれば、ビジネス/技術プロセスが作成されます。つまり、このデータを更新するために「テーブルを更新」プロシージャが実行されます。または、プライマリ駆動テーブルの更新/挿入トリガさえ？
この練習はアドバイスですか？それをより安全にする方法はありますか？
理想的な解決策は、基礎となるクエリを最適化することです。
SSMSでは、低速クエリを実行し、実際の実行計画（Ctrl + M）を含めると、クエリがデータベースに対してどのように実行されているかをグラフィカルに表示します。 SQLが欠落している索引を推奨場合
SET STATISTICS IO ON;
詳細については、任意の要素の上にマウスを置くと、予測行の値と返される実際の行の値を確認できます。これが変化すると、テーブルの統計が大幅に更新され、クエリオプティマイザが最高の実行計画。
使用[データベース名]
GO
EXEC sp_updatestats
ビュー/クエリの最適化にまだ運：データベース内のすべてのテーブルのためにこれを行うに ？
トリガーを更新しない限り、新しい列が「最適化」テーブルに挿入されないように、スキーマがビュー/テーブル上で変更されたかのように更新トリガーに注意してください（ソーステーブルに新しい列を追加するとします）。
リアルタイムデータをレポートするビジネス要件でない場合は、レポート用に最適化された別のテーブル（DataMartとよく似ています）を持つことにあまり害はありません.SQL Agentジョブを使用して、 -ピーク時間。 このアプローチにはいくつかの短所ががあります。
より収納スペース/重複データ
は、キャッシュヒットを減少リフレッシュ時に、より複雑なデータベース
追加のワークロード
あなたはキャッシングと考えることができます。数分ごとに複雑なクエリの結果をテーブル/キャッシュに更新/リフレッシュするので、ユーザーは数分前のデータが表示されます。それはあなたのために受け入れられるかもしれません。また、[インデックス付きビュー]（https://msdn.microsoft.com/en-AU/library/ms191432.aspx）も参照してください。しかし、彼らはむしろ[厳しい制限]（https://www.brentozar.com/archive/2013/11/what-you-can-and-cant-do-with-indexed-views/）を持っています。 –
ありがとう@VladimirBaranov - それは役に立ちます。インデックス付きビューを使用したかったのですが、ビュー内で、またはビューで使用される関数内でピボットを行う必要があるため、制限を破っています。私の唯一の選択肢は、キャッシュされたテーブルのようです。 – Craig