Discriminator column support in TPT inheritance
Currently, a discriminator column is only possible in TPH scenarios. The rational behind this is that in TPT the entity type can be inferred by joining. This is true but costly. In a serious application with many rows, the existence of a discriminator can have many benefits. For instance: one can create a composite index on the discriminator and primary key, on the base table (I could also use an index on primary key, filtered by the discriminator).
Randy Bigbie commented
Any word from Microsoft on this? If they believe adding this is possible but just doesn't have the time, please say so. If they believe this is possible but wants the community to submit the solution via open source, please say so. If they believe this is not possible, please say so. If they believe this is bad design, then can someone provide an alternative for when I want to create a view which queries addresses and I want to display the type of address in a list, on my report, for my users to read. If I am not thinking correctly on this, can someone correct me? Thanks!
Juliano Gonçalves commented
Please consider this one. It would make it much easier to work with table per type when you need to know the object type but not retrieve it's properties.
Martin Brown commented
In my case I'm trying to map to a database that was created by a different application that needs the discriminator column and I have no control over the schema.