2017-11-14 11 views
0

私は、セッションごとに別々のテーブルに特定のセッションデータを保持するデータベースを作成しています。例えばProductsABCDというテーブルがあります。このテーブルは、ABCDがセッションIDであるセッションにアクセスできる製品を保持しています。優雅ではありませんが、私は何をしなければなりません。現在、私は形式でこのデータにアクセスします。Microsoft SQL Serverセッション固有のシノニムを作成

DECLARE @Session AS VARCHAR(MAX) = 'ABCD' 
DECLARE @strSQL AS VARCHAR(MAX) 

SET @strSQL = 'SELECT * FROM Products' + @Session 
EXEC (@strSQL) 

非常に簡略化されたバージョンを、しかし、これまでの動的SQLを使用したことのある人は、これは非常に醜いなっいかに早く教えてくれます。私は現在シノニムを使用するオプションを検討しています。私はこれらを動的SQLで設定してから、動詞なしで同義語にアクセスすることができます。例えば

DECLARE @Session AS VARCHAR(MAX) = 'ABCD' 
DECLARE @strSQL AS VARCHAR(MAX) 

SET @strSQL = 'CREATE SYNONYM myProducts FOR Products' + @Session 
EXEC (@strSQL) 

SELECT * 
FROM myProducts 

DROP SYNONYM myProducts 

同義語がグローバルにアクセス可能であるように、複数のユーザーがオンラインである場合にのみ、単一のユーザーは、その実行可能な選択肢ではないテストしているとき、これは動作しますが。一度に1つのセッションにしかアクセスできない同義語を作成する方法を知っている人はいますか?テンポラリテーブルは、単一のセッションでしかアクセスできないのと同様です。

多くのありがとうございます。

追加情報:

ここでの状況は、価格が表示されているもの、製品が表示されているかを定義し、ここで遊んでいくつかのビジネス・ロジックがあることがあり、在庫レベルがなどにアクセス可能であるか、これらのそれぞれは、グローバルに保存されていますセッションの開始時に作成されたテーブルは、セッションディスポジションまたはタイマーでクリーンアップされます。

これらは、セットアップストアドプロシージャが終了すると有効期限が切れるため、一時テーブルに格納することはできません。システムで利用可能なデータのセッション数/数が多いため、セッションパラメータをフィールドとして持つ単一のテーブルに保持することはできません。これは、パーティショニングが本当にオプションになる前に開発されました。ストアドプロシージャの大幅な改訂が必要になります。これは継承されている既存のシステムであることを覚えておいてください。

ここでのdbセッションは、データベースへの単一の接続を開き、そのセッションを開いたままにするIISセッションです。これは、ログアウト時に送信された廃棄セッション、または適切に廃棄されなかった古いセッションをクリアするタイマーによってクリアされます。

私は、接続の期間中、またはストアドプロシージャの特定の呼び出し中にのみ、一意の同義語を探しています。シノニムが別のセッションやストアド・プロシージャで使用できない場合は、いずれも動作します。

+0

あまりにも曖昧な縫合とソリューションのコンセプト。ここでは「セッション」とは何ですか?セッションに独自のグローバル永続オブジェクトがある理由セッションの中断や誰かが一度に多くのセッションを開始したらどうなるでしょうか? –

+0

@IvanStarostinメインの質問に詳細を追加しました。私が働いているパッケージは、丁寧な "ユニークな"ものです! –

+0

同じログイン(dbプリンシパル)で異なるセッションを実行していますか? –

答えて

1

このクエストを回避するには、セッションごとのユーザーを作成し、セッションごとのスキーマにすべてのテーブルを配置し、このスキーマをこのユーザーにデフォルト設定し、execute as <session-user>ですべてを実行し、テーブルの前にスキーマを指定しないでください。同じ名前のテーブルを保持することができます(しかし、別のスキーマで)。この場合、スキーマはdboであるべきです。そして、いつか全解決策を再考しようとするかもしれません。

+0

私はこのアイデアが気に入っていますが、現在の移植でうまくいくかどうかはわかりませんが、それはアプローチそのものではなくデータベースの外にある項目のためです。私はそれを試して、それがどのように行くか見るつもりです。 –

+0

私はこれを調べて問題を見つけました。プロシージャ内でselectが呼び出されると、位置の優先順位はsysスキーマ、プロシージャのネイティブ・スキーマ、データベースのデフォルト・スキーマです。ユーザーのデフォルトスキーマは考慮されません。 Usersスキーマは、動的SQLを使用し、動的から離れる場合にのみ有効です。これは、プロジェクトのこの部分全体の理由です。これを回避するにはどんな方法でも大歓迎です。 –

関連する問題