I have two simple models I'm about to create in an existing Rails app. One is a
NAICSCode which has the following attributes:
description, the other is
SICCodes which has those same attributes, plus an attribute called
Both models are just wrappers around data storage for those attributes (no individual methods at this point), and both
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
NAICS being a type.
Without any methods is there any benefit besides having one less table in the database?
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.
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.
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.
Join 24,647+ developers who get early access to new screencasts, articles, guides, updates, and more.