3

カスタム ユーザー権限には、次のようなものがあります。

  UserId        permission
 11100001        ViewThis
 11100001        ViewThat
 11100002        EditThis
 11100003        EditThat

ここで、ViewThisたとえば特定のコスト センターをターゲットにするなど、よりカスタマイズして、特定のユーザーが特定のコスト センターの従業員のみを表示できるようにしたいと考えています。だから私は列を追加しましたCostCenter。その場合NULL、ユーザーはすべてのコスト センターを表示できることを意味します。問題は、たとえば、他のいくつかの権限ViewThatもカスタマイズする必要があることです。問題は、カスタマイズまたは制限が特定のコスト センターを対象としておらず、契約タイプなどの他の要因を対象としていることです。したがって、権限を持つユーザーは、ViewThat特定の契約タイプの従業員に限定する必要があります。そこで、別の列を追加しましたContractTypeID。このフィールドが不要な権限では、この列を無視する必要があります。場合によっては、特定のアクセス許可に 2 つ以上のカスタマイズ/制限フィールドが必要になることがあります。

現在の問題は、権限にカスタマイズ/制限を追加する必要があるときはいつでも、テーブルが水平方向に成長していることです。このようなジレンマに対処するためのより良い方法またはベストプラクティスはありますか?

4

3 に答える 3

2

これをデータモデルで正規化する方法があります。例を示しましょう。

ここに画像の説明を入力

表UserとPermissionは明確だと思います。Accessibleアクセスを制限したいものを保存しますCostCenter：、、ContractType...

あなたの説明から、Accessibles と Permissions の特定の組み合わせを定義したいことを理解しています ( CostCenterのViewThis、ContractTypeのViewThatなど)。したがって、これらの組み合わせを で定義できます。AccessiblePermission

これらの組み合わせを取得したら、 でそれらをユーザーに割り当てることができますUserAccessiblePermission。

これは、認可の定義部分です。

承認の実施部分は、ユーザーが特定の権限を持たないすべてのアクセシビリティに対するすべての権限を付与するビジネス ロジックで構成する必要があります。特定の権限がある場合、権限はなしに変わります。

これは、これを行うための 1 つの方法にすぎません。それがあなたのすべての要件に 100% 一致したとしたら驚きですが、何らかの方向性が示されることを願っています。

于 2013-09-24T20:55:52.227 に答える
0

リレーショナル データベースは、実際には最善の策ではない場合があります。あなたのデータは非常に構造化されていないように見えます。これは、キーと値のペアを格納するだけの xml または NoSQL データベースに適しています。通常、ユーザー、ロール、および users_to_role テーブルを格納できます。ここで、ロール テーブルにはロールの名前のみが保持され、それをコードにチェックインします。

リレーショナル データベースに行き詰まっている場合は、ロールごとにテーブルを作成できます。各テーブルは、ユーザーとそれが付与する権限を参照します。つまり、ユーザー ID と CostCenter を持つ ViewThis テーブルです。これにより、新しいテーブルを作成する必要があるため、新しいアクセス許可を追加するのが難しくなりますが、常に列を追加する必要があります。これにより、各権限が分離され、テーブル内でより集中的に保持されます。

于 2013-09-24T19:48:14.730 に答える