Database Design

Table Splitting in EF Core: When to Use It (and Why It Hurts Sometimes)

September 28, 2025 · 10 min

Your Customer entity has 47 properties. Most queries only need the basic information: name, email, and contact details. But every time you load a customer, EF Core pulls all 47 columns from the database, including the large ProfileData JSON blob that’s rarely used.

This is where table splitting can help: split your large entity into multiple classes that map to the same table, loading only what you need when you need it.

But table splitting is a double-edged sword. Use it wrong, and you’ll make performance worse, not better.

Understanding Table Splitting

Table splitting maps multiple entity classes to the same database table:

// Single table with many columns
CREATE TABLE Customers (
    Id int PRIMARY KEY,
    Name nvarchar(100),
    Email nvarchar(200),
    Phone nvarchar(20),
    -- Frequently accessed columns above
    
    ProfileData nvarchar(max),
    Preferences nvarchar(max), 
    MarketingMetadata nvarchar(max),
    LastLoginDetails nvarchar(max),
    -- Rarely accessed columns below
    CreatedAt datetime2,
    ModifiedAt datetime2
);

Instead of one large entity, you create multiple focused entities:

// Frequently accessed data
public class Customer
{
    public int Id { get; set; }
    public string Name { get; set; }
    public string Email { get; set; }
    public string Phone { get; set; }
    
    // Navigation to extended data
    public CustomerExtended Extended { get; set; }
}

// Infrequently accessed data
public class CustomerExtended
{ …

Read more

EF Core: One-to-One vs. One-to-Many (A Painful Lesson)

September 14, 2025 · 6 min

The difference between a One-to-One and a One-to-Many relationship in Entity Framework Core isn’t just academic. On my last project, choosing the wrong one led to two weeks of painful migrations, late nights, and a whole lot of dotnet ef database update anxiety.

It started with a simple feature: each tenant in our multi-tenant app needed a settings object. A Tenant has one Settings. Simple. So, we modeled it as a One-to-One relationship. What could go wrong?

Six months later, the requirements changed. Now, the business wanted an audit trail. They needed to see who changed a setting and when. Suddenly, our single Settings record per tenant was a huge problem. We needed a history, a collection of settings over time. Our rigid One-to-One schema was now a roadblock, and I was the one who had to fix it.

This experience taught me a hard lesson: your data model has to account for the future, not just the current sprint.

The Basics: What’s the Actual Difference?

Most of us get the concept, but let’s quickly recap how EF Core sees them.

A One-to-One relationship is a tight coupling. Think User and UserProfile. A user has exactly one profile. The profile can’t exist without the user. In the database, the primary key of UserProfile is also its foreign key back to User.

// The principal entity
public class User
{
    public int Id { get; set; }
    public string Username { get; set; }

    // Navigation property to the dependent
    public UserProfile Profile { …

Read more