I have a Rails app with HighSchoolTeam and ClubTeam models. I'm currently using Single Table Inheritance (STI) with Team. That means I only have a Teams table in my database, no High_School_Teams or Club_Teams tables.

What seems appropriate to me would be for HighSchoolTeam and ClubTeam to have their own tables in the database and also to inherit from a Team model. This doesn't seem like a common approach in Rails though. So I'm wondering a) if that is actually the case and b) if so why, if not what are the tradeoffs. Also, how do things work in server-side frameworks other than Rails?

1 Answer 1


The Rails API states:

If you don't have a type column defined in your table, single-table inheritance won't be triggered. In that case, it'll work just like normal subclasses with no special magic for differentiating between them or reloading the right type with find.

It also mentions that generally in Single Table Inheritance (STI),

all the attributes for all the cases are kept in the same table

Thus, the main issue with STI would be ending up with empty columns.

To decide whether to use STI or "normal" subclassing depends on the case, respectively. The main trade-off would be storage costs (size of the database) vs. convenience (readability, size of code base) especially if you plan on using rails associations.

As a rule of thumb I would suggest to only use "normal" subclassing if

  • you do not plan to have several models with associations to both classes (convenience/DRY)

  • you have very different columns/attributes in the two tables/classes (ending up with several null columns in STI for each model)


  • disk space matters

else use STI (or polymorphism).

Finally, I don't know how this is managed in other frameworks. Others may comment on this if they feel like it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.