Search for existing suggestions

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).

56 votes
Sign in
(thinking…)
Password icon
Signed in as (Sign out)

We’ll send you updates on this idea

Alireza Haghshenas shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

4 comments

Sign in
(thinking…)
Password icon
Signed in as (Sign out)
Submitting...
  • Randy Bigbie commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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.

Feedback and Knowledge Base