Single Table Inheritance vs Delegated Types in Rails: What's the Deal?

vincent — Tue, 29 Jul 2025 05:04:52 +0000

So you're building a Rails app and you've got some models that are related but not quite the same. Maybe you have different types of users, or various kinds of content, or whatever. Rails gives you a couple of ways to handle this, and honestly, it can be pretty confusing to figure out which one to use.

Let's break down Single Table Inheritance (STI) and Delegated Types - what they are, when they're awesome, and when they'll make you want to pull your hair out.

Single Table Inheritance: The "Throw Everything in One Bucket" Approach

STI is like that one drawer in your kitchen where you put all the random stuff. It works, but it gets messy fast.

Here's the basic idea: you have one database table that stores different types of related objects. Rails figures out what type each record is using a type column.

Let's See It in Action

# Your base class
class Vehicle < ApplicationRecord
end

# Your specific types
class Car < Vehicle
end

class Motorcycle < Vehicle
end

class Truck < Vehicle
end

And your database table looks something like this:

# Migration time!
class CreateVehicles < ActiveRecord::Migration[7.0]
  def change
    create_table :vehicles do |t|
      t.string :type, null: false  # This is the magic column
      t.string :make
      t.string :model
      t.integer :year
      t.integer :doors        # Only cars need this
      t.integer :cargo_capacity # Only trucks care about this
      t.boolean :has_sidecar  # Motorcycles only

      t.timestamps
    end

    add_index :vehicles, :type  # Don't forget this!
  end
end

When you create records, Rails handles the type stuff automatically:

car = Car.create(make: "Toyota", model: "Camry", doors: 4)
# Rails sets type: "Car" behind the scenes

Car.all # Only gets cars
Vehicle.all # Gets everything

Pretty neat, right?

Why STI Can Be Great

It's Simple: One table, straightforward queries. Your brain doesn't have to work too hard.

It's Fast: No joins needed most of the time. Your database is happy.

Rails Loves It: Everything just works the way you'd expect. Associations, validations, callbacks - they all play nice.

class Vehicle < ApplicationRecord
  validates :make, :model, :year, presence: true

  scope :recent, -> { where(year: 2020..) }
end

class Car < Vehicle
  validates :doors, presence: true, inclusion: { in: 2..5 }
end

# This stuff just works
recent_cars = Car.recent
all_recent_vehicles = Vehicle.recent

But STI Can Also Drive You Crazy

Your Table Gets Weird: As you add more types, you end up with tons of columns that are NULL for most records. It's like having a form where most fields don't apply to you.

Database Constraints Are a Pain: Since columns need to be nullable for some types, you can't enforce much at the database level. Your data integrity depends entirely on your Rails code not screwing up.

Adding New Types Sucks: Want a new vehicle type? Hope you enjoy writing migrations to add columns that 90% of your existing records won't use.

Everything's Coupled: All your types are stuck with the same table structure. If cars need to track something completely different from motorcycles, tough luck.

Delegated Types: The "Each Thing Gets Its Own Space" Approach

Delegated Types are the Marie Kondo of Rails patterns. Everything gets its own place, and it's all very organized. They showed up in Rails 6.1, so they're the new kid on the block.

Instead of cramming everything into one table, each type gets its own table, and they're connected through what's basically a fancy polymorphic relationship.

Here's How It Works

# Your "interface" class
class Entry < ApplicationRecord
  delegated_type :entryable, types: %w[Message Comment]
end

# Your actual implementation classes
class Message < ApplicationRecord
  include Entry::Entryable
end

class Comment < ApplicationRecord
  include Entry::Entryable
end

And now you've got multiple tables:

# The main entries table
class CreateEntries < ActiveRecord::Migration[7.0]
  def change
    create_table :entries do |t|
      t.string :entryable_type, null: false
      t.bigint :entryable_id, null: false
      t.string :title  # Shared stuff goes here
      t.datetime :published_at

      t.timestamps
    end

    add_index :entries, [:entryable_type, :entryable_id], unique: true
  end
end

# Messages get their own table
class CreateMessages < ActiveRecord::Migration[7.0]
  def change
    create_table :messages do |t|
      t.text :body
      t.string :recipient

      t.timestamps
    end
  end
end

# Comments get their own table too
class CreateComments < ActiveRecord::Migration[7.0]
  def change
    create_table :comments do |t|
      t.text :content
      t.references :post, null: false, foreign_key: true
      t.integer :rating

      t.timestamps
    end
  end
end

Working with it looks like this:

# Creating stuff
message = Message.create(body: "Hello world", recipient: "user@example.com")
entry = Entry.create(entryable: message, title: "Welcome Message")

# Getting the actual object
entry.entryable # Returns the Message
entry.message   # Same thing, but more convenient
entry.message?  # true

# Querying by type
Entry.messages  # Just the message entries
Entry.comments  # Just the comment entries

Why Delegated Types Rock

Clean Tables: Each type only has the columns it actually needs. No weird NULL columns everywhere.

Flexibility: Want to add something to messages but not comments? Go for it. Each type can evolve on its own.

Database Integrity: You can set up proper foreign keys and constraints on each table. Your database can actually help keep your data clean.

Type Safety: Rails gives you nice convenience methods, and it's clear which types are allowed.

Easier Testing: You can test each type independently without worrying about irrelevant columns.

But Delegated Types Can Be a Pain Too

More Complex: Multiple tables, polymorphic relationships - there's more moving parts to keep track of.

Slower Queries: Want to do something across all types? You're probably looking at joins, which can be slower than STI's single-table approach.

Rails Conventions Get Weird: Some things that "just work" with STI require more thought with delegated types.

Migration Overhead: Changes to shared behavior might require touching multiple tables.

So When Should You Use What?

Go With STI When...

Your Types Are Pretty Similar: Like different kinds of users where the main difference is permissions and maybe a few extra fields.

You Query Across Types A Lot: If you're constantly doing things like "show me all the things from this week," STI will be faster.

Performance Is Everything: You need the absolute fastest queries and can live with some table messiness.

It's Not Going to Get Complicated: Your inheritance hierarchy is pretty stable and not likely to grow into a monster.

Here's a good STI example:

class User < ApplicationRecord
  # All users have name, email, etc.
end

class AdminUser < User
  # Just adds some admin methods and maybe a couple fields
end

class ModeratorUser < User
  # Similar deal - mostly the same as regular users
end

Go With Delegated Types When...

Your Types Are Really Different: Like different kinds of notifications where email needs subject/body/headers but push notifications need badge counts and sounds.

Data Integrity Matters: You want the database to help enforce rules, not just rely on Rails code.

Types Need to Evolve Separately: Email notifications might grow a bunch of email-specific features that have nothing to do with SMS notifications.

Each Type Has Complex Logic: When each type has its own substantial set of validations, associations, and behavior.

Here's where delegated types shine:

class Notification < ApplicationRecord
  delegated_type :notifiable, types: %w[EmailNotification PushNotification SMSNotification]
end

class EmailNotification < ApplicationRecord
  include Notification::Notifiable
  # Tons of email stuff: subject, html_body, text_body, 
  # sender info, bounce handling, etc.
end

class PushNotification < ApplicationRecord
  include Notification::Notifiable  
  # Push-specific stuff: badges, sounds, deep links, etc.
end

class SMSNotification < ApplicationRecord
  include Notification::Notifiable
  # SMS stuff: phone numbers, character limits, etc.
end

Performance: The Real Talk

STI Performance

STI is usually faster for basic stuff:

# These are fast with STI
Vehicle.count
Car.where(year: 2020..).count
Vehicle.where("created_at > ?", 1.week.ago)

But it can get slow when your table gets really wide or you have a lot of sparse data.

Delegated Types Performance

Delegated types require more complex queries:

# This needs a JOIN
Entry.includes(:entryable).where(entryable_type: 'Message')

# But this can be optimized with better indexes
Message.joins(:entry).where(entries: { published_at: 1.week.ago.. })

The trade-off usually works out in favor of delegated types when you're doing a lot of type-specific queries or when you can set up really good indexes on the individual tables.

What If You Need to Switch?

Sometimes you start with one approach and realize you need the other. It's not fun, but it's doable.

STI to Delegated Types

This usually happens when your STI table gets too messy:

class MigrateToDelgatedTypes < ActiveRecord::Migration[7.0]
  def up
    # Create tables for each type
    create_table :cars do |t|
      t.integer :doors
      t.timestamps
    end

    # Move the data over
    Vehicle.where(type: 'Car').find_each do |vehicle|
      car = Car.create!(doors: vehicle.doors)
      vehicle.update!(
        vehicleable_type: 'Car',
        vehicleable_id: car.id
      )
    end

    # Clean up the old structure
    remove_column :vehicles, :type
    remove_column :vehicles, :doors
    add_column :vehicles, :vehicleable_type, :string, null: false
    add_column :vehicles, :vehicleable_id, :bigint, null: false
  end
end

Delegated Types to STI

This is less common but happens when you realize the complexity isn't worth it:

class MigrateToSTI < ActiveRecord::Migration[7.0]
  def up
    # Add all the columns you need
    add_column :entries, :type, :string
    add_column :entries, :body, :text        # From messages
    add_column :entries, :recipient, :string # From messages
    add_column :entries, :content, :text     # From comments
    # etc...

    # Move data into the main table
    Entry.includes(:entryable).find_each do |entry|
      case entry.entryable
      when Message
        entry.update!(
          type: 'MessageEntry',
          body: entry.entryable.body,
          recipient: entry.entryable.recipient
        )
      # handle other types...
      end
    end

    # Drop the old polymorphic stuff
    remove_column :entries, :entryable_type
    remove_column :entries, :entryable_id
  end
end

Testing: Keep Your Sanity

Testing STI

Pretty straightforward - test your base class and each subclass:

# Test the shared behavior
RSpec.describe Vehicle do
  it "validates required fields" do
    vehicle = Vehicle.new
    expect(vehicle).not_to be_valid
  end
end

# Test type-specific stuff
RSpec.describe Car do
  it "validates doors" do
    car = Car.new(make: "Toyota", model: "Camry", year: 2020)
    expect(car).not_to be_valid
    expect(car.errors[:doors]).to include("can't be blank")
  end

  it "inherits parent scopes" do
    expect(Car).to respond_to(:recent)
  end
end

Testing Delegated Types

A bit more complex since you've got the interface and the implementations:

# Test the interface
RSpec.describe Entry do
  it "works with messages" do
    message = Message.create!(body: "Test", recipient: "test@example.com")
    entry = Entry.create!(entryable: message, title: "Test Entry")

    expect(entry.message?).to be true
    expect(entry.entryable).to eq(message)
  end
end

# Test the implementations
RSpec.describe Message do
  it "can be used as an entryable" do
    message = Message.create!(body: "Test", recipient: "test@example.com")
    entry = Entry.create!(entryable: message, title: "Test Entry")

    expect(message.entry).to eq(entry)
  end
end

The Bottom Line

Look, both patterns are useful, and Rails wouldn't include them if they weren't solving real problems. The key is understanding what problem you're actually trying to solve.

If your types are pretty similar and you want simple, fast queries, STI is probably your friend. If your types are really different and you want clean, flexible schemas, delegated types are worth the extra complexity.

And honestly? Don't stress too much about making the "perfect" choice upfront. Start with what makes sense now, and if it stops working for you, you can always refactor later. That's what migrations are for, right?

The most important thing is to pick something and ship your app. You can always optimize later when you have real data and real usage patterns to guide your decisions.

Let's see...

vincent — Sun, 12 May 2024 11:10:00 +0000

I have in my toolbox a tool. The tool is a computer programming language called Ruby. With it, I would like to carve out a section of my life with. Let's see how it goes.

DEV Community: vincent