Database 数据库设计：关于约束的Discrimator与Separate表_Database_Entity Framework_Schema

Database 数据库设计：关于约束的Discrimator与Separate表

database entity-framework

Database 数据库设计：关于约束的Discrimator与Separate表,database,entity-framework,schema,Database,Entity Framework,Schema,我一直在两种方法上来回奔波，无法确定哪种方法更好（或者我为什么可能会走错方向）我有3个不同的网站供3种不同类型的用户使用，但它们共同构成了整个系统。例如，员工的管理门户、客户的客户门户和供应商的供应商门户。在这里，我将这些不同的实体表示为“域” 每个域都有自己的用户集和角色集—因为每个门户的业务性质不同，所以每个门户中的用户和关联角色也不同（例如，一个门户有报告，另一个门户没有，所以一个门户有“报告”角色）我没有将User子类型设置为“StaffUser”，因为它包含普通用户不需要的字段和对

我一直在两种方法上来回奔波，无法确定哪种方法更好（或者我为什么可能会走错方向）

我有3个不同的网站供3种不同类型的用户使用，但它们共同构成了整个系统。例如，员工的管理门户、客户的客户门户和供应商的供应商门户。在这里，我将这些不同的实体表示为“域”

每个域都有自己的用户集和角色集—因为每个门户的业务性质不同，所以每个门户中的用户和关联角色也不同（例如，一个门户有报告，另一个门户没有，所以一个门户有“报告”角色）

我没有将User子类型设置为“StaffUser”，因为它包含普通用户不需要的字段和对其他表的引用（如Team、Department等）

-------------------------------
|域| |角色|
-----------------                                >
|                              |
|                              |
|                              |
-----------------             -----------------
|用户| |用户|角色|
-----------------不要为此使用继承。当您想将“普通”用户转变为管理员时会发生什么？（或将客户转换为供应商等？）您不能，因为对象不能更改其类型。留给你的是丑陋的选择，比如删除和重新创建用户。如果一个用户同时在两个域中工作怎么办？继承根本不能支持这一点
有时，人们试图声称在他们的系统中，这种情况从未发生过，但在现实世界中确实发生过，而遗产实际上在这里并不能给你带来很多好处。为什么要为使用它付出代价
相反，您应该将“DomainAUser”信息作为一个单独的表，并具有从用户到DomainAUser的关联/导航，因此将有一个User.DomainA
属性，对于非DomainA用户，该属性将为空 考虑了很长一段时间你的答案，没有错。但是，现在我可以重复使用用户，如果他们更改电子邮件地址/密码，将影响他们对与其关联的所有域（读：网站）的访问。
-----------------             -----------------
| Domain        |             | Role          |
-----------------  <--------- -----------------
| DomainId (PK) |             | RoleId (PK)   |
|               |             | DomainId (FK) |
-----------------             -----------------
        >                              >
        |                              |
        |                              |
        |                              |
-----------------             -----------------
| User          |             | User_Role     |
-----------------  <-------   -----------------
| UserId (PK)   |             | UserId (PK)   |
| DomainId (FK) |             | RoleId (PK)   |
-----------------             -----------------

-----------------
| 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)  |
----------------