Question

I’ve been batting back and forth over two ways of going about something and cannot settle on which I think is better (or see why I maybe going about it the wrong way).

I have 3 distinct web sites for 3 distinct types of user, but together they make the whole system. For example, an Admin portal for staff, a Customer portal for customers and an Supplier portal for suppliers. Here I have represented these different entities as “Domain”.

Each domain has its own set of users and its own set of roles – as the nature of business for each portal is distinct, so are the users and so are the associated roles within each portal (for example, one portal has reports, another doesn’t, so one portal has an “Reports” role).

I’ve not included the fact that I subtype User off to a “StaffUser”, because that has fields and references to other tables which a plain user does not need (such as Team, Department etc).

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

In the above example, I can have n Domains, each with n Users and n Roles and Users can be associated with Roles. 4 tables, it’s incredibly simple, everything has a discriminator value.

In my web application (for argument sake I am using .NET MVC and Entity Framework), when I wish to assign roles to a user, I select all the Roles of the same Domain type as the User, and save the pairings I want.

However, if there is some sort of slip up in the production of the code which selects domains (someone uses the wrong enum on the Domain type) and now suddenly we’re matching Users from one Domain type to Roles from another Domain type… chaos ensues.

How is this scenario preventable? Can it be enforced in SQL? Am I worrying about something unlikely to happen? I’ve seen far more ridiculous SNAFUs than that in my time.

So, what if I bring a table-per structure into it:

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

In this example, DomainARole inherits from Role, DomainAUser inherts from User. If we want to add more domains, we need a new table for each type and that can be a lot of tables (of which in my case there won’t be more than 3 “domains” anyway). Is this needless overcomplication?

The first benefit is that a DomainAUser can only ever have a DomainARole… it’s enforced right there referentially. I never have to worry about matching two pairs with discriminators again because everything is neatly seperated off into tables.

The second benefit is that should requirements change in the future (DomainAUser needs extra fields that DomainBUser doesn’t) I have the tables in place and it’s flexible.

Am I missing a simplier way of pulling this off? Currently I’ve been in favour of the 2nd, more table heavy version.

Is there a way to enforce the constrains I need using the discriminators? Am I overcomplicating matters? I really can’t decide.

Answer 1

Do not use inheritance for this. What happens when you want to turn a “regular” user into an administrator? (Or customer into supplier, etc?) You can’t, because objects can’t change their type. You are left with ugly choices, like deleting and re-creating the user. What if one user works in both domains? Inheritance can’t support that at all.

Sometimes people try to claim that in their system this never happens, but in the real world it does, and inheritance actually doesn’t buy you very much here. Why pay the price of using it?

Instead, you should make the “DomainAUser” info a separate table and have an association/navigation from User to DomainAUser, so there will be a User.DomainA property, which will be null for non-DomainA users.