Is it possible to combine two entities with different PKs?

Question

I'm new to the entity framework so hopefully this is a really simple question... Can I combine these two entities?

Here is the db...

I want the final to be something like this...

Answer 1

I think that you are asking, "Is it true that I cannot use a related entity as a discriminator field for table per hierarchy inheritance?" And that is correct. You would need a separate discriminator field to use table per hierarchy inheritance. However, you would probably not need the ResourceType entity in this case, since the specific type of an entity itself is enough to tell you which icon to use.

However, I would question whether inheritance is the correct design here.

Using inheritance in an O/R mapping is always a bit of a compromise, because you will either use a design like table per hierarchy which does not map naturally to a well-formed relational schema, or a design like table per type, which means the DB server has to work harder to serve up even a simple list. I think that the common design guideline to "Favor composition over inheritance" is even more true for O/R mappings in particular than it is for OOD in general.

I understand that the images you've added are just examples to illustrate your question, and that your real design may be more complicated, but let's use it as an example:

The subtypes in the diagram (Application, File, etc.) have only one property which is not in the parent type. For many of the subtypes, the "extra" property is the same, Link. One of them has a different property (Filename), but I will note that filenames can be expressed as URIs.

In addition to the inheritance design you showed in your illustration, you could also model this design without using inheritance. In this case, you would remove the subtypes, but keep the ResourceType entity.

Now let's consider what some sample queries might look like with each design:

// get books with inheritance:
var bi = from b in Context.RelatedResources.OfType<Book>()
         select b;

// without
var bc = from b in Context.Resources
         where b.ResourceType.ID == ResourceType.Book // static property you define on ResourceType 
         select b;

Neither one strikes me as terribly bad. For me, that's reason enough not to use inheritance. The most compelling advantage of inheritance in an O/R mapping is to be able to easily retrieve entities of different subtypes in a single list. But you can already do that with this design. Because the composition design is easier to implement, less complicated, and will use your database more efficiently, I would prefer it unless there is a compelling advantage to inheritance, which I don't see here.