状況：非正規化されたテーブルが多数ある大規模なデータベースがあります。サマリーテーブルの同期を維持するために、データを再サマリーする必要があることがよくあります。データを最新の状態に保つために計算列を使用することについて、話し合いました。トリガーについても話しましたが、それは別の議論です。
サマリーテーブルでは、標準IDと標準の説明がテーブルに格納されるようにテーブルを非正規化しました。これは本質的に、テーブルが十分な頻度で再要約されることを前提としているため、標準の説明を変更すると、要約テーブルでも変更されます。悪い仮定。
質問：サマリーテーブルの標準の説明を、標準のテーブルから標準の説明を選択する派生/計算列にした場合はどうなりますか？100,000〜500,000行のテーブルに計算列をドロップすると、パフォーマンスが大幅に低下しますか？
テーブル内の計算列は、その行の値からのみ導出できます。計算列をルックアップすることはできません。そのためには、ビューが必要になります。
テーブルでは、名前をテーブルに少し非正規化しても、パフォーマンスへの影響は無視できる可能性があります。DBCC PINTABLEを使用して、サーバーにテーブルをキャッシュに保持するようにヒントを与えることができます。
リアルタイムで更新を行う必要がある場合、実際には唯一のオプションはトリガーです。更新する名前に対応するID列にクラスター化インデックスを配置すると、全体的なI / Oの量が減るはずです（特定のIDのレコードは同じブロックまたはブロックのセットになります）。トリガーが原因である場合は、これを試してください。パフォーマンスの問題。
計算された列は、計算が集中的でなく、多数の行で実行されない場合は問題ありません。あなたの質問は、「計算列をドロップすることでヒットするか」です。この列がクエリで使用されるインデックスでない限り (コンプ列にインデックスを付けるのは本当に悪い考えです - DB に応じてできるかどうかわかりません)、削除してもパフォーマンスが低下することはありません (クエリとクランチするデータが少なくなります)。 ）。
標準テーブルに説明がある場合は、計算を使用せずに ID から結合する必要があります。
あなたは本当の問題であるかもしれないことをほのめかしました、そしてそれはあなたのデータベースのスキーマです。私は以前、このような問題を抱えていました。システムが 1 つのことを処理するように構築されていて、レポートのようなものをボルトオン/インする必要がある場合です。スキーマをリファクタリングしてすべてのニーズのバランスを取ることなく、ビューを使用するという Sunny のアイデアは、ほぼ唯一の簡単な方法です。
クレンジングされた DDL とデータ、およびデータベースから取得しようとしているものの例を投稿したい場合は、主観的ではない回答を提供できる場合があります。
sql2005以降の問題を明確にするために：
この機能は、パフォーマンスのために SQL Server バージョン 6.5 で導入されました。DBCC PINTABLE には、非常に望ましくない副作用があります。これらには、バッファー プールを損傷する可能性が含まれます。DBCC PINTABLE は不要であり、追加の問題を防ぐために削除されました。このコマンドの構文は引き続き機能しますが、サーバーには影響しません。