Table Per Hierarchy Inheritance In EF Core

Hello there! It's fantastic that you're diving into how computers organize information, especially with something like Entity Framework. Think of me as your guide, and we'll break down "Table Per Hierarchy inheritance" into simple, bite-sized pieces, just like figuring out how a cool magic trick works!

First, let's get a handle on a couple of basic ideas:

1. What is "Inheritance"?

Imagine you have a general category, like "Animals."

• All animals have some things in common, right? They breathe, they eat, they move.
• But then you have specific types of animals, like "Mammals" (which are animals, but also give live birth and have fur) and "Birds" (which are animals, but also lay eggs and have feathers).
• This idea, where a more specific type (like a "Mammal") is also a more general type (an "Animal") and gets all the general stuff automatically, is called inheritance. The Mammal inherits characteristics from the Animal.

In computer programming, we use inheritance to organize our code. We might have a general "Vehicle" object, and then "Car," "Truck," and "Motorcycle" objects that inherit from "Vehicle."

2. What's a "Table" in a Database?

Think of a table in a database like a super-organized spreadsheet.

• It has columns (like Name, Age, FavoriteColor).
• It has rows, and each row is one complete item (like "Bob, 12, Blue" would be one row).

When we talk about "Entity Framework," it's a helpful tool that makes it easy to take our computer objects (like our "Vehicle" or "Car" objects) and automatically save them into these database tables, and also read them back out again. It's like a magical librarian for your computer's information!

3. Putting it Together: Table Per Hierarchy (TPH)

Now, here's the puzzle: If you have "Vehicles," "Cars," "Trucks," and "Motorcycles" in your program, and you want to save them all into your database, how should you organize your spreadsheets (tables)?

"Table Per Hierarchy" (often shortened to TPH) is one way to do it, and it's super straightforward. It says:

"Let's put all the related types of things into one big spreadsheet."

Here's how it works with our Vehicle example:

Let's say you have these different types of vehicles in your program:

• Vehicle (the general type): Every vehicle has a Make (like Ford, Honda) and a Model (like F-150, Civic).
• Car (a specific type of Vehicle): A car also has a NumberOfDoors (like 2 or 4).
• Truck (another specific type of Vehicle): A truck also has a CargoCapacity (how much weight it can carry, like 1000 kg).
• Motorcycle (yet another specific type of Vehicle): A motorcycle might have a HasSidecar property (true or false).

With Table Per Hierarchy, Entity Framework creates just ONE database table. Let's call it Vehicles.

This Vehicles table would have columns for all the properties that any of the vehicle types might have, plus a special column to tell us what kind of vehicle each row represents:

Let's look at what's happening here:

1. One Big Table: See how all cars, trucks, and motorcycles are in the same table? That's the core idea of TPH.
2. Common Columns: Columns like VehicleId, Make, and Model are filled in for every row, because all vehicles have these properties.
3. Specific Columns: Columns like NumberOfDoors, CargoCapacity, and HasSidecar are only filled in when they apply.
   • For the Toyota Camry (a Car), NumberOfDoors is 4, but CargoCapacity and HasSidecar are NULL (which means "empty" or "not applicable").
   • For the Ford F-150 (a Truck), CargoCapacity is 1500, but NumberOfDoors and HasSidecar are NULL.
4. The "Discriminator" Column: This is the secret ingredient! Entity Framework automatically adds a special column (usually called Discriminator, or sometimes something like VehicleType). This column tells you exactly what type of vehicle each row is. When Entity Framework reads the row for VehicleId = 1, it sees "Car" in the Discriminator and knows to create a Car object in your program.

Why use TPH?

• Simple to set up: It's often the default and easiest way to get started with inheritance in Entity Framework.
• Easy to query all types: If you want to find all vehicles, no matter if they're a car or a truck, it's super fast because they're all in one place. You just query the Vehicles table.

Are there any downsides?

• Lots of empty spaces: If you have many different types of vehicles, and each type has very unique properties, your table might end up with many NULL values. This usually isn't a huge problem, but it's something to notice.
• Table can get wide: If you have hundreds of specific properties across many inherited types, your one table might become very wide with many columns.

Think of TPH as making one giant "Master Inventory" list where you keep track of everything, using a special "Item Type" column to know exactly what each item is.

You've just taken a big step in understanding how complex data is organized in the computer world! Do you have any questions about this, or would you like to explore another angle?

Sources:

• https://learn.microsoft.com/en-us/ef/core/modeling/inheritance
• https://www.entityframeworktutorial.net/efcore/inheritance-in-entity-framework-core.aspx
• https://www.c-sharpcorner.com/article/inheritance-with-entity-framework-code-first-approach/