1

ロールを含むテーブルがあります。多くのユーザーを役割に割り当てることができます。パーミッションをロールに割り当てることができ、そのロールにすべてのユーザーにパーミッションを付与できます。

500 百人の役割に権限を割り当てると、実質的に 500 の権限割り当てが作成されました。

ロールに割り当てられた各アクセス許可について、そのロールを持つ各個人が持つアクセス許可の種類を決定する際に実行する必要がある複雑な計算を指定します。たとえば、「READ_EMAIL」パーミッションを「ACCOUNTANT」ロールに割り当てる場合、その際、許可するメールボックス タイプを指定する変数も含めます。それらの特定のグループへのアクセス。

したがって、どの個人がどの特定のメールボックスにアクセスできるかを知りたい場合は、アクセス許可、ロール、およびユーザーのテーブルに参加するだけでなく、検索を行う必要があります。理由については、ここのスペースでは説明するのが難しいため、時間がかかります消費し、速くすることはできません。

私が遭遇する問題は、計算されたすべてのアクセス許可の割り当てをビューで公開すると (これらすべてのテーブルを結合し、複雑で時間のかかる計算を実行する)、非常に長い時間がかかることです。

ユーザーを役割に割り当てるか、権限を役割に割り当てることによってアクティブ化されるトリガーを介して入力される、ユーザー役割権限テーブルを簡単に作成できることに気づきました。権限が役割に割り当てられると、その役割を持つ各個人のレコードが挿入され、その時点で複雑な検索が行われ、このテーブルに 500 のレコードが挿入されます。ユーザーがロールに割り当てられるたびに、権限と複雑なルックアップが生成されます。このテーブルからロール割り当てテーブルとアクセス許可割り当てテーブルへの外部キーが存在し、カスケード削除が行われます。

役割の割り当てに対するアクセス許可はまれであるため、大幅に遅くなっても問題ありません。私のテーブルへのアクセスの 99.99999% は SELECT です。

この方法の欠点はありますか? リアルタイムのデータが必要です。私は自分自身のオンコミットの具体化されたビューを設計しているだけですか? 他の提案はありますか?

4

1 に答える 1

2

独自のオンコミットの具体化されたビューを設計しているように聞こえます。ここでコミット時のマテリアライズド ビューを使用して結果をキャッシュできなかった理由はありますか?

マテリアライズド ビューの更新に失敗すると、トランザクションのコミット操作が失敗し、ロールバックが強制されます。したがって、データと具体化されたビューが同期しなくなることは実際にはありません。確かに、トリガーベースのソリューションではバグが発生する可能性がはるかに高くなります (特に、複数のセッションで同時に変更が行われている場合)。同期ロジックの作成は Oracle に任せたいと思います。

于 2010-10-05T14:21:39.433 に答える