1

私の雇用者アプリケーションの多くは、データを特定のユーザーまたはグループのセットに制限するための同様の内部許可構造を共有しています。グループは入れ子にすることもできます。

このアプローチで現在直面している問題は、アクセス許可の列挙が非常に遅いことです。現在の方法では、多くのカーソルと一時テーブルを持つストアド プロシージャを使用しています。これは小規模なアプリケーションでは問題なく機能しましたが、現在、急速に成長している特定のシステムが 1 つあり、速度が低下し始めています。

基本的なテーブル構造は次のとおりです。

tblUser { ユーザー ID、ユーザー名、WindowsLogonName }

tblGroup {グループID、名前、説明、システムフラグ}

tblGroupGroup { GroupGroupID, 名前, }

tblGroupUser { GroupUserID, 名前, }

そしてそれをすべて結びつけます。

tblPermission { PermissionID、SecurityObjectID、SecuredID、TableName、AllowFlag }

..のような行が含まれています

'5255-5152-1234-5678', '{グループの ID}', '{tblJob 内の何かの ID}', 'tblJob', 1

'4240-7678-5435-8774', '{ユーザーの ID}', '{tblJob 内の何かの ID}', 'tblJob', 1

'5434-2424-5244-5678', '{グループの ID}', '{tblTask​​ 内の何かの ID}', 'tblTask​​', 0

すべてのグループを列挙し、保護された行の ID を取得するためのより効率的な方法が必要ではないでしょうか?

事態をさらに複雑にします。ユーザーが行へのアクセスを明示的に拒否されている場合、これはすべてのグループ権限を無効にします。これはすべて MSSQL にあります。

4

3 に答える 3

0

Recursive Common Table Expressions ( CTE ) 階層クエリを使用できると思います。検索するとたくさんの例が見つかります。これはそれらの1つです。

于 2009-07-15T20:48:43.837 に答える
0

おそらくあなたの設計は問題ありませんが、実装/コードが間違っています。

いくつかの考え：

  • ID 列はすべて GUID ですか? 非推奨キンバリー・L・トリップの記事
  • おそらくキーまたは INCLUDE 内の他の列を含む、すべての外部キーのインデックス
  • 通常のメンテナンス？例: 断片化されたインデックス、日付の統計情報など
  • すべてのデータ型が一致していますか (FK がないことを前提としています): データ型の優先順位と暗黙の変換エラーが忍び寄る可能性があります

いくつかのスキーマ情報とパフォーマンスの低いコードの例が役立つ場合があります

于 2009-09-05T12:13:36.460 に答える
0

tblPermission を 2 つのテーブル (グループ用とユーザー用) に分割すると便利だと思います。そこにグループとユーザーの両方を含めることで、設計が複雑になるようです (おそらく、それがストアド プロシージャが必要な理由です)。

tblPermission テーブルを (tblUserPermission や tblGroupPermission のようなものに) 分割したいが、tblPermission のように見えるテーブルの表現が必要な場合は、2 つのテーブルのデータを結合するビューを作成できます。

お役に立てれば。ストアド プロシージャの機能の例はありますか?

于 2009-07-14T21:07:44.373 に答える