SQLテーブルを構造化して一致させるか、結果を返さない方が良いでしょうか？

Question

興味深いデザインの質問があります。私は、コストの異なるさまざまなバージョンのプログラムを用意し、マネージャタイプのユーザーがプログラムの一部へのアクセスを他のユーザーに許可することを許可するために、プロジェクトのセキュリティ面を設計しています。それはWebベースになり、当社のサーバーでホストされます。

「リソース」または画面ごとに単純な許可または拒否オプションを使用しています。

私たちは多数のリソースを持ち、ユーザーはさまざまなグループを設定して、ユーザーがアクセスを制御できるようになります。各ユーザーは1つのグループにしか属しません。

私はこれを念頭に置いて2つのアプローチがあり、パフォーマンス面でSQLサーバーのほうが好都合であるかどうか不思議でした。

オプションA アクセステーブルにエントリが存在するということは、アクセスが許可されていることを意味します。これにより、情報を格納するデータベースの列は必要ありません。結果が返されない場合、アクセスは拒否されます。

これは小さいテーブルを意味すると思いますが、クエリ全体が一致するものがないと判断するためにテーブル全体を検索しますか？

オプションB ビット列は、許可/拒否を制御するデータベースに含まれています。これは、常に結果が見つかることを意味し、より大きなテーブルを作成することを意味します。

思考？

Answer 1

許可/拒否のみになる場合は、ユーザーとリソース間の単純なリンクテーブルが正常に動作します。リンクテーブルのUser-Resourceに入力されたエントリがある場合は、アクセスを許可します。

UserResources 
------------- 
UserId FK->Users 
ResourceId FK->Resources 

とSQLが（ユーザーIDとRESOURCEID）にクラスタ化インデックス付き

if exists (select 1 from UserResources 
where UserId = @uid and ResourceId=@rid) 
set @allow=1; 

ようになり、クエリでも数百万レコードに疑いの余地なく、高速になります。

Answer 2

オプションBに投票します。オプションAを使用している場合、ユーザーが存在する場合には、そのユーザーが入ることができると仮定すると、最終的には、ユーザーにアクセスを拒否するという問題が発生します。ユーザーレコードを削除せずに

ユーザーをロックアウトしたいが、アカウントを完全に破棄したくない場合があります。 1つのそのようなインスタンス（必ずしもあなたのユースケースにリンクされているわけではありません）は、お支払いに失敗した場合で、お支払いを再開するまでアカウントを切断します。アカウントを一から作成し直すのではなく、ユーザーの履歴をすべて失うのではなく、支払いを再開するときに有効にしたいので、レコードを削除する必要はありません。

Answer 3

B.これにより、データが完全であるかどうか（たとえば、許容/拒否可能な機能を追加した場合）の方がはるかに優れたチェックが可能になります。

また、テーブルサイズは、（100,000+などの）多数のレコードが含まれていることがわかっているテーブルに対してのみ考慮する必要があります。この質問にテーブルサイズの考慮事項を入力する時間を取っても、余分なハードドライブの容量よりもコストがかかります。

Answer 4

アプローチAですが、暗黙のうちに明示的に拒否することもあります。私はいくつかのユースケースを作成して、最終的なロジックが動作することを確認しますが、いくつかの例があります。

User1 is in group1 and group2. 
User2 is in group1 
User3 is in group2 

---

Folder1 allows group1 and deny group2. 
User1 is denied. 
User2 is allowed. 
User3 is denied. 

私はあなたのアプローチのユーザー1が許可されるだろうと考えています。