I need to implement solution with 1 base class and 3 sub-classes (4 classes)
Base class: User
Sub-classes: Client, OfficeUser, Employee
In my database I have only 3 tables : Users, Clients and Employees.
I don't have OfficeUsers table since all data that I need is already in Users table.
In the future I want to be able to create report lisitng number of Clients, Employees and OfficeUsers.
I don't want to use TPH since I have lots of non-nullable fields in Clients and Employees table.
Should I create OfficeUsers table with only UserId so I can implement TPT?
It looks for me as not very good design - having table with only PK so I can map it properly - please correct me if this is the way to do it.
Another option was to have UserType colum within Users table and use it as discriminator but will it work with TPT? Is it possible to create TPT with 1 missing table and use discriminators, looks like mixing TPT and TPH which I think is not possible.
Thanks in advance for your answers.
EDIT:
Please also consider this scenario:
I'm introducing new class called MobileUser which also has the same fields as User. In that case I have no way of knowing how many MobileUsers and how many OfficeUsers is the system without introducing new column for user type.
Is having in this scenario 2 empty tables (only PK) is better/worse than creating dependency in my queries on number of tables and additionally preventing me from using some LINQ queries (please see my comments under Ladislav Mrnka answer )
EDIT 2:
There is a chance that I'll have to add fields to OfficeUser in the future so I'm starting to think that empty table can somehow be an option, at least C# code (queries) would look cleaner. Let me know if you have better approach.
I think this is just a problem of perspective, rather than an architectural one... because whatever you do, you end up with a single PK table.
You can make an OfficeUsers table, which can contain just the PK of the User... just don't make it an inherited type. Now you have a list of all users who use the office, which you can query against. The structure is exactly the same, but the thinking is a bit different.
If you had multiple offices, you'd have a table of offices with an id, then your OfficeUser would have it's own type table, as the extra field would be the office foreign key... giving you the distinction you wanted.
But, as you only (I presume) have one office, you don't need a foreign key, so you just need one table to hold the users who use the office... it's "6 of one, half a dozen of the other", exactly the same really, whichever way you choose.
This is why I'd go with your instinct in your 2nd edit, you might add more fields later, so you may as well make an "empty" type... because either way, you'll end up with a table that just stores PKs.