0

私はデータ仮想化ソリューションに取り組んでいます。ユーザーは、作成したクエリのフィルターとして独自の SQL クエリを作成できます。データベースから何かを選択するたびにこのフィルター クエリを実行する必要がないようにしたいと思います (複雑な一連の結合になる可能性があります)。

私の考えは、 # スクリプト レベルで一時テーブルを使用し、接続を維持することでした。この #temp テーブルは、ユーザーがフィルターを変更した場合にのみ選択されますが、更新されます。私は実際にストアドプロシージャからそれを使用でき、テーブルはその接続にスコープされているという考えです。

各接続に一意のグローバル一時テーブルを持たせるために、接続プロセス ID で名前を付けた動的 SQL および ## グローバル一時テーブルを使用することを提案した人からアイデアを得ました。これは、ストアド プロシージャ間での一時テーブルの共有を克服するためでした。しかし、それは少し不器用なようです。

以下のコードで簡単なテストを行ったところ、問題なく動作するようでした

-- Run script at connection open from some app
SELECT * INTO #test
FROM   dataTable

-- Now we can use stored procedures with #test table
EXECUTE selectFromTempTable

EXECUTE updateTempTable @sqlFilterString

EXECUTE selectFromTempTable

私が見ることができる唯一の本当の問題は、おそらく数時間かかる可能性がある期間中、接続を維持する必要があることです。1 人のユーザーが複数の接続を同時に実行できます。1 つのデータベース サーバーのユーザー数は最大 20 人です。それが大きな問題である場合は、アプリケーションが必要に応じてそれらを閉じたり開いたりできるようにして、各ユーザーが一度に 1 つの接続しか開かないようにすることができます。そして、使用していない場合は閉じて、必要に応じて再度開いて、クエリの実行を待つ必要があるかもしれません。

これは悪い習慣でしょうか？または、フィルター クエリを実行しないことによるパフォーマンス上の利点をすべて無効にしますか? これは SQL Server 2008 以降にあります。

4

1 に答える 1

0

spid（プロセスID）をキー値として使用して、永続的なテーブルを作成すると思います。各接続には独自のプロセスIDがあるため、誰でもそれを使用してテーブル内のエントリを識別できます。

create table filter( 
  spid int, 
  filternum int, 
  filterstring varchar(255), 
  <other cols> );
create unique index filterindx on filter(spid, filternum);

次に、ユーザーがフィルターエントリを作成すると、次のようになります。

delete from filter where spid = @@spid
insert into filter(spid, filternum, filterstring) select @@spid, 1, 'some sql thing'
insert into filter(spid, filternum, filterstring) select @@spid, 2, 'some other sql thing'

where spid = @@spid 次に、 etcを選択して、各ユーザーのフィルター値にアクセスできます。

于 2013-01-23T09:29:37.087 に答える