Question

I just wanted to throw this question out there to do a sanity check on my ORM design to make sure the way I’m doing it isn’t some crazy anti-pattern. My situation is that in my design I have a class that has an association relationship with 4 other classes. So if I had classes A, B, C, D, and E classes B,C,D, and E would all have an “Has-An” relationship to Class A. Currently the only way that I know of in LINQ-To-Sql to define a relationship is through creating a foreign key column in A for every entity that has a relationship to it. While this works it has the disadvantage that in the database there is four columns where three of the columns will always be null. Is this just a limitation of ORM tools? Any advise or suggestions would be appreciated.

Answer 1

So I forget the exact name for this type of association, but I believe it’s called Polymorphic association. It’s my understanding that LINQ Entities doesn’t support polymorphic associations the way that Ruby on Rails does, but what you’d want to do is:

1. Create tables A, B, C, D, E without defining their relationships to one of each other.
2. Assign a UniqueIdentifier column to each table (this is a GUID).
3. Create a “Relationships” table (probably want to come up with a better name.
4. The relationships table would have two columns. Something like Source and Destination and both would be of type GUID or UniqueIdentifier (I forget what MSSQL server calls it).

The bad part is that MSSQL can’t enforce the foreign key relationship (this is why LINQ Entities doesn’t support it). So that’ll have to be done in your business logic or in a StoredProcedure.

This does give you the option of adding a type F and use the same table to expressing a Has-A relationship between F and A.