Let’s suppose I’m designing an app for defining and storing
information about Widgets. Widgets have a number of properties. They
have a color, a shape, a size, a weight, a texture, etc. Each of these
properties is chosen from a pre-defined list of possibilities for that
My initial thought was that each property subclasses a parent property
class WidgetProperty < ActiveRecord::Base
Its migration self.up would look something like this:
create_table widget_properties do |t|
t.column :value, :string
t.column :type, :string
Presumably it’s subclasses would all be along these lines:
class WidgetColor < WidgetProperty
class WidgetShape < WidgetProperty
. . . and so on. In the properties database, we’d have tables defining
properties such as:
:id => 1, :value => :blue, :type => ‘WidgetColor’
:id => 2, :value => ‘yellow’, :type => ‘WidgetColor’
. . .
:id => 36, :value => ‘square’, :type => ‘WidgetShape’
There about two dozen different kinds of property, each with 6-8
values. But essentially they’re all the same - just an id and a string
value. What I haven’t yet figured out is the following:
Is STI really the way to go here? I’m not sure if it’s buying me
anything or not.
In my Widget model class, should my Widgets “have_one
:widget_color, have_one :widget_shape” and so on, or should they
“have_many :widget_properties”? Or maybe they should
Question 2 is where most of my confusion is. The properties aren’t
really “things” themselves, they’re just attributes that are assigned
to Widgets, and otherwise have no meaning. But many Widgets are going
to share properties (for example, there will be a lot of square, blue
Widgets), so the properties don’t exactly belong to the Widgets.
I have a feeling there is probably a pretty straightforward way to do
this (since this situation isn’t exactly unique, I’m sure), but for
whatever reason it isn’t coming to me. I’m hoping someone can toss me
a lifeline here.
Thanks very much.