データウェアハウスのステージング領域にインデックスを追加することをお勧めしますか？
MSSQL 2012、ステージングエリア、EDW、キューブ、レポートに構築されたデータウェアハウスがあります。
ステージング領域では、テーブルは、DWHを埋めるために使用されるシステムをサポートするテーブルの1：1コピーです。ステージングエリアテーブルはTRUNCされ、毎日（毎晩）補充されます。次に、それらのテーブルのビューは、EDWへのETLプロセスの入力を提供します。
EDWで使用できるコピーを提供することに加えて、これらのステージングテーブルは、クエリでソースシステムに圧力をかけないように、一部のアナリストによってMSSQL Management Studioを使用してクエリされます。
EDW向けのETLとアナリストのクエリの両方について、これらのテーブル（の一部）にインデックスを付けるとパフォーマンスが（大幅に）向上する可能性があると思います。毎日TRUNCされる（大きな）テーブルにインデックスを作成することは賢明ですか？そうでない場合、なぜですか？そして、どのような種類のインデックス（クラスター化vs非クラスター化vs完全に他のものか）？
これらのコピーされたテーブルはETL（選択クエリによる）にのみ使用されることを除いて、あなたが説明したのと同様の状況があります。私たちがそれにどのように取り組んだかを説明しますが、それが環境に有効かどうかを評価する必要があります（質問に対するJon Seigelのコメントを参照）。
コンセプトは簡単です：
- ステージング領域でこれらの「コピー」テーブルにインデックスを付けて、クエリを可能な限りサポートします。ほとんどのインデックス（特に、スキャンによってヒットする大きなテーブル）は、列ストアインデックス（2012年も同様）ですが、一部は非クラスター化インデックスをカバーしています。先ほど述べたように、これらのテーブルは（現時点では）ETLの選択クエリにのみ使用されるため、すべてのクエリが列ストアインデックスまたはカバーする非クラスター化インデックスのいずれかでサポートされていることを確認できます。
- ソースシステムからステージング領域へのデータポンプ（コピー）の前に、インデックスを削除して、一括読み込みを可能な限り高速にし、ソースシステムに最小限の時間でアクセスできるようにします。データポンプが完了したら、それらを再作成します。再作成が「動的に」行われるようにロジックが設定されます（インデックスはハードコードされていないため、ドロップされたすべてのインデックスは、そのまま正確に再作成されます）。これにより、ドロップ/作成コードを維持する必要なく、インデックス作成を変更します。
このアプローチは私たちにとってはうまくいき、ドロップ/再作成はインデックス付きテーブルにロードするよりも高速です。列ストアインデックスの場合、パーティション分割とパーティションスイッチの使用を除いて、他に多くのオプションはありませんが、これらのテーブルに対してはそうしません（EDWファクトテーブルは別の話です）。