データウェアハウスの悪い習慣？
Datawarehouseのコンテキストでは、ETL内のファクトテーブルのレコードを更新する必要があります。
私たちがしたことの1つは、最も重いクエリの直前に非クラスター化インデックスを作成し、その後それらを削除することです。これにより、クエリでのテーブルのスキャンに費やす時間が大幅に短縮され、インデックスの構築に費やす時間による影響は非常に少なくなります（1〜2分）。
これは悪い習慣ですか？
注：現在、テーブルをパーティション分割することはできません。
それがあなたのために働くなら、それは良い習慣です。データベースには基本的に厳しいルールはありません。
ETLジョブの一時インデックスを構築することは、インデックスの構築がかなり高速であるため、必ずしも悪い習慣ではありません。非常に大きなテーブルで増分更新が比較的小さい場合はそれほど効率的ではないかもしれませんが、ここではそうではないようです。
唯一の注意点は、テーブルが時間とともに大幅に拡大することが予想される場合です。それらがETLの単なる作業テーブルである場合、それはおそらくOKです。テーブルが今後5年間で大量のデータを蓄積するファクトテーブルである場合、インデックスの再構築は時間とともに遅くなる可能性があります。
データのステージングでは、インデックスを削除してからロードすると、ステージングへの一括ロードがはるかに速くなり、ETLプロセスを提供するクエリをサポートするためにステージングテーブルにインデックスを追加する必要がある場合があります。
私が考えることができる唯一の悪いことは、インデックスを構築する間、関連するテーブルで新しい挿入/更新が問題になる可能性があるということです。
ただし、インデックスの作成中にデータを変更するためのユースケースがない場合、それは高速で実行可能なアプローチです。時間とスペースを節約できます。
これは完全に有効な方法ですが、更新よりも挿入によく使用されます。これはStack Exchangeの他の場所で説明されています（例 https://softwareengineering.stackexchange.com/a/78598/25946 ）。ただし、「インデックスの作成、更新、インデックスの削除」に必要な時間は、実際にインデックスなしで更新するよりも短いことを確認する価値があります。
インデックスをそのままにしておくことも検討する必要があります。明らかに、これは「作成、更新、削除」よりもさらに高速です。インデックスを適切な位置に維持すると、挿入と削除がわずかに遅くなりますが、クエリに役立つ場合があります。また、現在ETLに使用しているインデックスを変更して、クエリに役立つようにすることもできます。テーブルとクエリの詳細を提供できる場合は、より具体的な提案を提供できる場合があります。