0

私は何かについて 2 つの方法で行ったり来たりしてきましたが、どちらが優れていると思うかについて決めることができません (または、なぜ私が間違った方法で行っているのかを理解してください)。

私は 3 つの異なるタイプのユーザー向けに 3 つの異なる Web サイトを持っていますが、それらが合わさってシステム全体を構成しています。たとえば、スタッフ用の管理ポータル、顧客用のカスタマー ポータル、サプライヤー用のサプライヤー ポータルなどです。ここでは、これらのさまざまなエンティティを「ドメイン」として表しています。

各ドメインには独自のユーザー セットと独自のロール セットがあります。各ポータルのビジネスの性質は異なるため、ユーザーも、各ポータル内の関連するロールも異なります (たとえば、あるポータルにはレポートがあり、別のポータルにはレポートがないなど)。したがって、1 つのポータルには「レポート」ロールがあります)。

ユーザーを「StaffUser」にサブタイプしたという事実は含めませんでした。これには、プレーンユーザーが必要としない他のテーブルへのフィールドと参照 (チーム、部門など) があるためです。

-----------------             -----------------
| Domain        |             | Role          |
-----------------  <--------- -----------------
| DomainId (PK) |             | RoleId (PK)   |
|               |             | DomainId (FK) |
-----------------             -----------------
        >                              >
        |                              |
        |                              |
        |                              |
-----------------             -----------------
| User          |             | User_Role     |
-----------------  <-------   -----------------
| UserId (PK)   |             | UserId (PK)   |
| DomainId (FK) |             | RoleId (PK)   |
-----------------             -----------------

上記の例では、それぞれ n 個のユーザーと n 個のロールを持つn個のドメインを持つことができ、ユーザーはロールに関連付けることができます。4 つのテーブル、信じられないほどシンプルです。すべてに識別値があります。

私の Web アプリケーション (議論のために .NET MVC と Entity Framework を使用しています) で、ユーザーにロールを割り当てたい場合、ユーザーと同じドメイン タイプのすべてのロールを選択し、必要な組み合わせを保存します。

ただし、ドメインを選択するコードの作成になんらかの誤りがあり (誰かがドメイン タイプで間違った列挙を使用している)、突然、あるドメイン タイプのユーザーを別のドメイン タイプのロールに一致させている場合.. . カオスが続く。

このシナリオはどのように防ぐことができますか? SQLで強制できますか? 起こりそうにないことを心配していますか？私は当時、それよりもはるかにばかげた SNAFU を見てきました。

では、table-per 構造をそれに組み込むとどうなるでしょうか。

-----------------
| Domain        |
-----------------
| DomainId (PK) |
-----------------
        >
        |
        |
        |
-----------------             ------------ ----            ---------------
| DomainA       |             | DomainARole   |            | Role        |
------------ ----  <--------  -----------------  --------> ---------------
| DomainId (PK) |             | RoleId (PK)   |            | RoleId (PK) |
|               |             | DomainId (FK) |            |             |
-----------------             -----------------            ---------------
        >                              >
        |                              |
        |                              |
        |                              |
----------------              ---------------------------
| DomainAUser  |              | DomainAUser_DomainARole |
----------------   <-------   --------------------------|           
| UserId (PK)  |              | UserId (PK)             |
| DomainId (FK)|              | RoleId (PK)             |
----------------              ---------------------------
        |
        |
        |
        >
----------------
| User         |
----------------
| UserId (PK)  |
----------------

この例では、DomainARole は Role から継承され、DomainAUser は User から継承されます。さらにドメインを追加したい場合は、タイプごとに新しいテーブルが必要であり、それは多くのテーブルになる可能性があります (私の場合、とにかく 3 つを超える「ドメイン」はありません)。これは不必要な複雑さですか？

最初の利点は、DomainAUser は DomainARole しか持つことができないということです...それは参照によってすぐに適用されます。すべてがきれいにテーブルに分けられているため、2 つのペアをディスクリミネーターと照合することを心配する必要はありません。

2 番目の利点は、将来要件が変更された場合 (DomainAUser には DomainBUser にはない追加のフィールドが必要です)、テーブルが配置されており、柔軟性があります。

これをやってのける簡単な方法がありませんか？現在、私は 2 番目の、よりテーブルが重いバージョンを支持しています。

ディスクリミネータを使用して必要な制約を適用する方法はありますか? 私は問題を過度に複雑にしていますか? 本当に決められない。

4

1 に答える 1

0

これには継承を使用しないでください。「通常の」ユーザーを管理者に変えたい場合はどうなりますか？（または顧客からサプライヤへなど？）オブジェクトはタイプを変更できないため、できません。ユーザーの削除や再作成など、醜い選択肢が残ります。1人のユーザーが両方のドメインで作業している場合はどうなりますか？継承はそれをまったくサポートできません。

時々人々は彼らのシステムではこれは決して起こらないと主張しようとします、しかし現実の世界ではそれは起こります、そして継承は実際にここであなたをあまり買わないのです。なぜそれを使用する代償を払うのですか？

代わりに、「DomainAUser」情報を別のテーブルにし、UserからDomainAUserへの関連付け/ナビゲーションを行う必要がありUser.DomainAます。これにより、非DomainAユーザーの場合はnullになるプロパティが作成されます。

于 2012-08-15T11:49:58.017 に答える