来自多个不同表的EF多对多关系

Question

Let's say I have 4 tables: tbl_dogs , tbl_cats , tbl_birds and tbl_fish each with their own _Id columns, of course.. I want to create the ability to have many-to-many relationships between any of these tables. In my head, I picture a tbl_relationships table that has 2 columns: animal1_id and animal2_id and I can entries can be cat_12 | dog_3 cat_12 | dog_3 , bird_1 | dog_9 bird_1 | dog_9 , fish_8 | cat_4 fish_8 | cat_4 , etc. This is a 2 part question:

• 1) is this possible with EF code first? meaning the two columns on my "relationships" table can actually be pulled from multiple different tables? If so, how would I define that in the EF classes?
• 2) what if rather than animal1_id and animal2_id as the columns, I wanted to have parent_animal and child_animal so that when I went to look at a fish , I could pull all the child_animal records that have that fish as a parent_animal as well as all the parent_animal records that have that fish as a child_animal ?

Any help would be greatly appreciated, thank you!

Answer 1

It's not possible with any relational database. Entity Framework is beside the point. A foreign key has to be made to a specific table. Period.

The Python framework, Django does sort of what you're looking for with its generic content types, but it's more of a hack than anything. For each generically related item, two columns are set: one for the type of the object and one for the id of the object. There are no foreign keys, because again, foreign keys are impossible in this scenario.

In the framework code, in order to materialize the related object, they then issue a query to the correct table (based on the object type) using the object id. However, this is much simpler in Python than C# because Python is duck-typed.

You can technically achieve the same thing, in C# if you were properly motivated, but it would be an entirely manually endeavor. Entity Framework is of no help to you here. You would also need to employ reflection in order to materialize the right type in the end, and reflection is both a pain in the posterior and hugely inefficient (slow).

That said, since the specific scenario here deals with things all of a certain type, animals, you can sort of achieve what you're looking for with inheritance. In other words, you can create an Animal entity and then have each of Dog , Cat , Bird , Fish , etc. inherit from Animal . Then, you can create a foreign key to Animal and interact with any of them. However, you would only be able to interact with them as Animal s, not as specifically a Bird , for example.

Answer 2

If you need to have a single matrix table with just two columns, and you need each animal type to be in its own table, then Chris Pratt's answer is succinct.

If you can go with more than two columns but are forced to stick with individual animal tables, I would try to have a column for every animal table in the matrix table and turn this matrix table into a massive multi-columned monster.

If you are limited to two columns in the matrix table but can target a matrix table based on what parent/child combo you are looking for, then I would set up twelve matrix tables and have each of them for one of the two possible animal combinations for each pair of animal tables. Obviously you are going to have issues if the number of animal tables is actually much larger.

If the animal tables will all have identical columns (type/content/requirements) themselves, there is a possible workaround. You can have all animals in one table with an identifier that signifies what kind of animal it is. This would typically be a foreign key attached to a lookup table of animal types. Then you can have your matrix table as both parent and child columns, as they will have explicit relationships to just a single other table (the 'mass animal' table; both parent and child would point to its PK).

A more elegant possible workaround to the prior paragraph (which I haven't had a chance to use yet, so I am really hazy on its implementation with respects to gotchas) is Inheritance . Inheritance allows you to combine several tables that hold near-identical (in terms of fields and data types) collections of data, and be able to tell those collections apart by means of a discriminator. That way, as per the prior paragraph, you could have a single Animals table with a discriminator that indicates what each row is (cat, dog, etc.), and a matrix table where both the parent and child point to the ID of the Animals table. Since each column in the matrix table has an association to a unique table (instead of multiple tables), this could work out well.