my_report_user実行時にユーザー名でデータベースに接続するレポートがあります。レポートには多数のエンド ユーザーが存在する可能性があります。また、実行ごとに、データベースへの新しい接続が作成されますmy_report_user(接続プールはありません) 。
一度だけ作成できると思われる結果セットがあり (レポートの最初の実行時である可能性があります)、他のレポートの実行ではその内容を再利用できます。基本的に、レポートを実行するたびに、この結果セット (一時テーブルとして保存) が存在するかどうかを確認する必要があります。存在しない場合は、その結果セットを作成します。それ以外の場合は、利用可能なものを再利用します。
local一時テーブル (#) または一時テーブル (##)を使用する必要がありますglobalか?
誰かがそのようなことを試したことがありますか？（ほぼ同時のレポート実行など）
編集: Sql-Server 2005 を使用しています
ない
独自の制御下で結果セットをキャッシュする場合は、いかなる種類の一時テーブルも使用できません。tempdb に格納されている通常のユーザー テーブルを使用するか、独自の結果セット キャッシュ データベースを使用する必要があります。
一時テーブル、ボット #local および ##shared には、接続によって制御される有効期間があります。アプリケーションが切断されると、一時テーブルが削除されます。これは、説明した内容ではうまく機能しません。
本当に難しい問題は、これらのキャッシュされた結果セットを、混同せずに同時実行で取り込むことです (両方が「最初の」実行であると信じていた同時レポート実行からの重複項目を含む結果セットになってしまいます)。
補足として、SQL Server Reporting Services は既にこれをすぐに使用できます。データセットをキャッシュして共有したり、レポートをキャッシュして共有したりできます。すでに機能しており、テスト済みです。
#temp テーブルは特定のシナリオで役立つ場合がありますが、ベスト プラクティスとしては役に立ちません。グローバル ##temp テーブルの有効な使用法は、私自身の作業でも、それらについて書いた他の人の作業でもまだ見つけていません。私が考えることができる唯一のケースは、一時データストアを構築し、その後のいくつかのステップでそれを取得する必要がある BCP またはその他の外部プロセスです。その場合、ある種のキーとクリーンアップを処理するバックグラウンド プロセスを備えた永続的なテーブルを使用することをお勧めします。
現在、OLTP モードになっているようです。データベース ウェアハウジングについて調べておくと、間違いなく役に立ちます。