Question

I am trying to come up with a database design that would work with Entity Framework 4 Code First. Actually, I have no experience yet of EF4 Code First but as I understand it, if I write the code, it will create the database and tables.

The issue is this. There are various types of auctions, they all have some common fields and some specific ones. In the code I envisage having a base abstract class called Auction and subclasses like LowestUniqueBidAuction and EnglishForwardAuction etc.

Nothing surprising there. The problem is that I imagine the database structure to mimic this. I imagine an Auction table and a LowestUniqueBidAuction table and a EnglishForwardAuction table. In the Auction table I imagine a foreign key into one of these two tables for each row depending on the type of auction that that row is. I also imagine another column in the Auction table with the name of the derived auction table (such as EnglishForwardAuction).

The problem is that whenever I’ve ever created a foreign key I’ve had to specify the name of the foreign table into which the key points (which makes sense). In this case, however, there is one of many tables that the key could point. So there are many issues here. Firstly, I could simply not use a foreign key and just use an ordinary field, but then the database will not be able to maintain data consistency for me. The second issue is how will EF Code First handle this? In other words, how will it know that if I ask for all EnglishForwardAuction rows from the Auction table that it should look at the column with the table name and then join on the EnglishForwardAuction table to get the extra fields?

Has anyone ever faced similar issues?

Thanks,

Sachin

Answer 1

This problem is solvable in Entity Framework in a number of ways – read up on how EF handles inheritance and what strategies are available.

There are basically three strategies how to handle this:

(1) Table per Hierarchy

You have only one single table, that represents all possible sub classes. Of course, this means, several rows (that only exist in a given subclass) must be nullable, since they don’t show up / don’t exist in super classes or other subclasses.

(2) Table per Type

Each subclass gets its own table, and by default, the sub-types table shares the PK with the base classes’ table – e.g. PK = 1 in Auction will also be PK = 1 in EnglishForwardAuction. So your subclass tables reference the base table – not the other way around.

(3) Table per Concrete Type

Each concrete subclass (your separate auction types) gets its own table, but that table contains everything – all the columns, from that specific type, but also its base type.

Read more here:

• Inheritance in the Entity Framework
• Inheritance and Associations with Entity Framework Part 1
• Entity Framework Modeling: Table Per Hierarchy Inheritance
• Entity Framework Modeling: Table Per Type Inheritance

Searching for Entity Framework Inheritance and/or one of these strategies will reveal a lot more hits, too – that topic is very well covered and discussed on the interwebs! 🙂