準備されたレポートテーブルを更新するには、約5〜10分かかります。このテーブルを常に更新したいと思います（おそらく15分ごとに1回、または継続的に）。
このレポートテーブルは非常に頻繁に（1分間に何度も）クエリを実行しますが、これを長時間維持することはできません。データが15分前であれば問題ありません。
テーブルを削除して再作成することはできません。テーブルの内容を削除して再作成できません。
2つのテーブルを交換する（もう一方を構築するときに一方から読み取る）など、使用する必要のある手法はありますか、それともこの5〜10分のプロセスを大規模なトランザクションに配置しますか？
同義語を使用しますか？。作成時に、これはtableAを指します。
CREATE SYNONYM ReportingTable FOR dbo.tableA;
15分後、tableBを作成し、同義語を再定義します
DROP SYNONYM ReportingTable;
CREATE SYNONYM ReportingTable FOR dbo.tableB;
同義語は実際のテーブルへの単なるポインタです。このようにして、実際のテーブルの名前変更などの処理が単純化および抽象化され、すべてのコード/クライアントが使用します。ReportingTable
編集、2011年11月24日
同義語はすべてのエディションで使用できます。パーティションの切り替えはエンタープライズ/開発者のみです。
編集、2012年2月
標準版ではテーブル全体を切り替えることができます（おそらくExpress、テストされていません）
ALTER TABLE .. SWITCH ..
ターゲットテーブルが空の場合、これはシノニムよりもエレガントです。
編集、2012年2月（2）
また、SQLServerで結合されたテーブルをキャッシュするようにスキーマを介してローテーションすることもできます
はい、テーブルを交換する必要があります。まだ行っていない場合は、レポートテーブルに別のサーバーまたは他の物理パーティションを使用することを検討してください。
ほぼリアルタイムのレポートに推奨されるアプローチは、運用システムから読み取りをオフロードし、レポートシステムで書き込みアクティビティを読み取りアクティビティから分離することです。
少なくとも論理的には、準備されたテーブルを用意することで、最初の部分を実行しました。ユーザー用の読み取り専用テーブルと更新用の別のテーブルを交換すると、トランザクション間の書き込みと読み取りの競合がなくなります。コストはユーザーのキャッシュレイテンシーですが、必要に応じて、準備時間を最小限に抑え、テーブルをより頻繁に交換するための手順を実行できるはずです。
リアルタイムレポートでの設計の選択の詳細については、WayneEckersonによるよく書かれた論文「OperationalBIのベストプラクティス」をお勧めします。
2つのテーブルを持つことは、最も単純な解決策のように聞こえます。
このプロジェクトでは、2つのテーブルと、ビューの作成/変更を使用して切り替えました。