レコード レベルのセキュリティを適用しているようです。
最善の方法は、セキュリティ テーブルを 1 つ持つことです (各テーブルStates、City、Branch or Post Codeおよびキャッチオール アクセス許可Allには独自の ID があります。これはできるだけ小さい数値データ型にする必要がありますが、ここではわかりやすくするためにテキストとして扱います。答え）：
UserID TableID RecordID
RecordIDnull 可能です。
単一のレコード:UserID = @x TableID = 'All' RecordID = Nullが入力された場合、そのユーザーはすべてのデータにアクセスできます。
ユーザーが州の data: へのアクセスを許可されている場合UserID = @x TableID = 'States' RecordID = 1、そのユーザーは ID = 1 の州に関連するすべての都市と郵便番号にアクセスできます。
ユーザーが都市の data: へのアクセスを許可されている場合UserID = @x TableID = 'City' RecordID = 1、そのユーザーは ID = 1 の都市に関連するすべての郵便番号にアクセスできます。
支店または郵便番号のデータへのアクセス権がユーザーに付与されている場合、UserID = @x TableID = 'Branch or Post Code' RecordID = 1そのユーザーは ID = 1 の支店または郵便番号のみにアクセスできます。
必要に応じて、追加のビット フィールドを追加できます:Denyが 1 に等しい場合、そのレコードへのアクセスを拒否します。これは、次のようなシナリオで役立ちます。市 "X" では、ユーザーはいくつかの郵便番号を除くすべてにアクセスできるため、市へのアクセスを許可し、除外された郵便番号へのアクセスを拒否します。
もちろん、許可記録がなければアクセスはありません。
もう少し単純なものが必要な場合は、地理テーブルごとに 1 つの権限テーブルを作成し、ユーザー レコードに「すべてのアクセス」ビット フィールドを作成できます。
アクセス許可テーブルのデータに従って地理テーブルをフィルター処理する SQL を生成する必要があります。
編集：
データ サイズ、プログラミングの単純さ、およびデータの維持のしやすさに関する質問者の懸念を考えると、次のようになります。
このアプローチは、データのオーバーヘッドを最小限に抑えるように設計されています。ユーザーがデータ セット全体またはデータ ツリーのサブツリー全体へのアクセスを許可 (または拒否) されている場合、必要なアクセス許可レコードは 1 つだけです。ユーザーごとの権限レコードの数が非常に多くなる可能性があるのは、ユーザーがブランチへのアクセスを少しずつ許可されている場合のみです。
3 つのテーブルからの関連データをアクセス許可 UI に集約し、データにアクセス許可を適用するためのコーディング作業が少しありますが、これは、合理的に有能なプログラマーが作成または理解する能力を超えてはなりません。適切にコメントされ、文書化されています。アプリケーションを担当するプログラマーが十分な能力を持っていないと予想される場合は、パーミッションをテーブルごとに個別のパーミッション セットに分割できますが、これは DBA にとってあまり役に立たない可能性があります。
このアプローチは各ユーザーに関連付けられる権限レコードの数を最小限に抑える必要があるため、DBA が必要とする数千の権限レコードを生成する、純粋に最下位レベルの許可のみの権限構造よりも維持するのがはるかに簡単です。これは、包含と省略のエラーがはるかに発生しやすいアプローチでもあります。私が説明したアプローチでは、ユーザーごとに数千ではなく、ほんの一握りの許可レコードしか必要としない場合があります。