New Post: Read Schema for a "table per type" database

The schema can be read fine - the problem is for the code generation part which has to reverse engineer the code first model.

We can identify the "shared primary key" which is a key part of this inheritance - the child table PK is also a FK to the parent table. There's a IsSharedPrimaryKey extension method for it.

But we don't then write the inheritance in the class definition- we do normal associations as if it was a 1:1 relationship (which is another way of looking at it).
Say you have Employee and Manager tables. A manager is always an employee.
In code first, you could have a Manager class that inherits from Employee. That's inheritance.
Or you could have a Manager class with an required Employee property. This is 1:1, and that's what we try to do now. Yes, in code you cannot tell that a Manager cannot be created without an Employee first, so that's domain logic.

Which you want depends mostly on business logic. I haven't seen a lot of TPT in the wild, and in fact I know a case (in Code First) where we ripped it out because it was inefficient.

For the moment I think we'll keep to the 1:1 modelling, but I'll think about how we can do inheritance as well.

Thanks for the input!