I have a shared type that I’d like to represent in a database. I need to know either if it’s possible with code first or if it’s bad design. (Please point to sources of your reasoning).
Here’s the layout:
public class A
{
public Guid Id;
public Guid ParentId; // Points to either B or C
public string Foo;
}
public class B
{
public Guid Id;
public virtual ICollection<A> ManyA { get; set; }
// Other fields
}
public class C
{
public Guid Id;
public virtual ICollection<A> ManyA { get; set; }
// Other fields
}
I’ve managed GUID PKs by using the [DatabaseGenerated(DatabaseGeneratedOption.Identity)] annotation, which I believe would make this possible.
The goal is to keep the A-table simple; I’d like it not to have B_Id and C_Id columns, as I think they’re unnecessary, and there may be a D type in the future that has many A just like B and C. Also, this scenario is used for a few other relationships.
I think the spirit of the problem is apparent, however the EF-specific class members are just there for illustration. If they need changing, so be it.
(I’m sorry for the contrived example, however exposing the true nature of this, IMO, doesn’t clarify the problem).
Also, I tried searching for hours! I don’t know the proper nomenclature to find a suitable answer. I’m pretty new to databases and EF in general.
I’ve found that I can make a common base type for both
BandCtypes. For example:And, based on this Msdn article, would result in Table Per Hierarchy database layout. TPH performs better versus TPT, which I was thinking could be an answer.
I was really hoping for something simpler, but performance is the bottom line, afterall