Ask A Question

Notifications

You’re not receiving notifications from this thread.

Single Table Inheritance: Good spot or not?

Brian Schwartz asked in Rails

I have two simple models I'm about to create in an existing Rails app. One is a NAICSCode which has the following attributes: company_id, code, name, and description, the other is SICCodes which has those same attributes, plus an attribute called year_first_appeared.

Both models are just wrappers around data storage for those attributes (no individual methods at this point), and both belong_to Company (which does have functionality and a purpose).

If these actually did anything besides store related data, I can see an advantage of creating a Code object (model) and using STI, with SIC or NAICS being a type.

Without any methods is there any benefit besides having one less table in the database?

Reply

I can't think of any other benefits. "Simpler" to manage from a database perspective, but complexity shifts to working with STI.

In this case, I usually do whatever feels easiest and just keep in mind that I need to be careful to consider this in the future anytime I start changing these around. Whatever you decide later on, you should be able to easily combine or separate these into different tables.

Reply

Ya, I'm on the fence. STI is really nice early on, but it's been a bit difficult for me to work with as apps get more complex. You may only have one differentiator now, but in the future you may have several which you'll have to work in. Something to watch out for.

Reply

I personally try to stay away from STI whenever possible. I haven't really had a use case for it besides being able to manage things easier from the db point. Like Chris said, it's whatever you feel is easiest and what you feel is maintainable in the long run.

Reply
Join the discussion
Create an account Log in

Want to stay up-to-date with Ruby on Rails?

Join 86,946+ developers who get early access to new tutorials, screencasts, articles, and more.

    We care about the protection of your data. Read our Privacy Policy.