Choosing the right entity relations approach

Question

Suppose I have a user table and role table

I have two role types, employee and employer

Inside user table, i have the following columns

• UserId

  FirstName

  LastName

  RoleId(foreign key -- one to many)

An employer can have related companies while employee can have related CVs

So is it better to define two additional tables (Employee, Employer) with one to one relation to User table, and have Company/CV foreign keys in there, or is it better to define User table like so

• UserId

  FirstName

  LastName

  CompanyId - leave blank for employee (allow null)

  CVId - leave blank for employers (allow null)

  RoleId

I was thinking about adding two additional tables(employee and employer), that seems like more reasonable, but then what is the use of the Role table, and also leaving blank seems like a doable approach, just don't show the fields when adding/editing new employee/employer...But I am not sure if there is any security concerns/drawbacks when doing it like this, that is why I want to seek advice from you guys

Answer 1

Both ways are common strategies for implementing inheritance on data-model, the first one is called TPT (Table per Type), and the second one is called TPH (Table per Hierarchy).

Here's a great article that describes & compares both strategies http://blogs.msdn.com/b/alexj/archive/2009/04/15/tip-12-choosing-an-inheritance-strategy.aspx

Which strategy is the Best? Trick question! In isolation of your requirements there is no 'Best' strategy. Here are some of the things you might want to consider when making your decision:

• Performance : Table Per Hierarchy is generally better performing, because no joins are necessary, everything is in one table. The decision becomes even more clear cut once the inheritance hierarchy gets wide or deep.
• Flexibility : Table Per Type is often used by ISVs, as it allows customizations without modifying the 'base' table. ie new subtypes can be added simply by creating new tables for those sub-types.
• Database Validation : TPH requires columns in derived types to be NULLABLE in the database, so that other derived types can be stored in the same table. Because of this it is possible to create rows in the table that are not valid according to the conceptual model. Ie the column is NULLABLE but the combination of a particular column being NULL and a particular discriminator or type is not valid. This means the database is not enforcing the conceptual model for you anymore. This is fine if all access to the database is via the EF, but if anything else is used, you can end up with 'dirty' data.
• Aesthetics : This one is completely subjective, but TPT feels more Object Oriented to me :)
• Storage Space : If your inheritance hierarchy has lots of types, then using TPH will result in lots of empty cells. If your database can handle 'sparse' columns well this probably isn't a real concern.

As you can see once you know what it is you are looking for it should be a pretty easy task to choose a strategy. Most of the time the recommendation is TPH because generally performance trumps these other concerns. But every situation is different, and the key is to understand exactly what you value, and then make the decision accordingly.