database - アクセス権データベース設計

Question

アクセス権を格納するためのデータベースを設計するためのより良いパターンはどれですか?

1. アクター {actorid, name, password, canpost, cancomment,canremoveuser, candothis, candothat}
2. アクター {actorid, name, password} 権限 {actorid, action, isallowed}

Answer 1

最初のオプションは可能な限り柔軟ではなく、2 番目のオプションは可能な限り管理しやすいものではありません。

アクセス制御の標準パターンはRole Based Securityと呼ばれます。ユーザーの数と、必要なさまざまな種類のアクセス許可の数の両方が増加するにつれて、ユーザーとアクセス許可のリンクの管理がますます難しくなる可能性があります。

たとえば、5 人の管理者と 50 人のユーザーがいる場合、各グループのアクセス許可を同期するにはどうすればよいでしょうか? ユーザーの 1 人が管理者に昇格した場合、何回編集する必要がありますか? 答えは、ユーザーからロールへ、およびロールからパーミッションへという 2 つの交差を作成することです。

Answer 2

オプション 1 は単純なシステムに適しています。1 つのクエリで、必要なすべての情報を含む 1 つの行が得られます。これは非常に効率的です。効率は「良い」です。そして、それはあなたのニーズに対して「より良い」とさえ言えるかもしれません.

オプション 2 は、アクション権限が時間の経過とともに予測できない方法で拡張される可能性が非常に高く、ユーザーが独自のサブシステムにのみアクセスできることを確認するために、本質的に分離されたモジュールによって使用される場合に最適です。アクターとアクセス情報の両方を同時に取得する場合、「結合」を実行する必要があるという点で、より複雑です。しかし、私はジョインが好きなので、効率が悪いと大声で言うつもりはありません。DBS はジョインが得意なように作られています。インデックスを賢く使用すれば、問題ありません。

リンク テーブルの使用は、コーディングの観点からはより複雑です。データを分離したため、それぞれの異なる部分を処理するより複雑なコードを作成する必要があります。しかし、個人的には、データの各一意の部分が独自の依存コードを持っているという点で、これは「良い」複雑さであると信じています。モジュール性と機能の単項カプセル化を可能にします。

Answer 3

ほとんどの場合、解決策 2 の方がはるかに優れていると思います。そのソリューションの「許可されていない」フラグを破棄し、ユーザーの特定の権利のみを権利テーブルに挿入します。