The Entity Framework supports 3 primary inheritance strategies:
In TPH, all data for a type hierarchy is stored in one table, and there is a discriminator column that is used to establish the type of a particular row (i.e. 'C' for Car or 'B' for Boat). Columns for Properties that are not shared across all types need to be nullable, even if they aren't nullable properties. Which means the database is not completely enforcing your null-ability constraints.
A TPH table might look something like this:
In TPT properties in a base type are stored in a shared table. For example a Vehicle table:
And then there is a table for each sub type, with columns for just newly declared properties and the key, so the tables can be joined. So there would be a Car table:
and Boat table:
In Table per Concrete Class there is a table for each class, and each of those tables has a column for every property of that type, i.e. a Car table:
And a Boat table:
Trick question! In isolation of your requirements there is no 'Best' strategy.
While the EF runtime supports TPC, the designer doesn't, and using TPC in the EF forces you to avoid associations in your base type. Because of these issues we generally discourage the use of TPC with the Entity Framework.
This means in most situations the question comes down to TPH or TPT?
Here are some of the things you might want to consider when making your decision:
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.
Let me know if you have any questions.