I am developing an application that will have 100’s of model classes
each derived from a single source class. Each model will have 4 similar
attributes but then have about a dozen unique ones each. I looked into
using STI but balked at creating tables with a 1000 columns. I then
looked at using inherits_from and creating an new table for each class
that holds the new class columns. Problem is, I’ll end up with 100’s of
tables, which also does not appeal to me.
My third solution, the one I am asking advice on, is this.
I create a single table with the 4 common columns and a dozen columns
with names such as float1, float2, float3, … , string1, string2, …
etc. Creating enough columns of each type to cover my largest subclass.
Then I use STI and for each class I map the generic columns to the nicer
names inside the subclasses. So in one class float1 may be miles/hour
while in another class it might be turkeys/hectare.
Does this sound like a reasonable approach?
Also, how would I map the generic names to nice names in my subclasses?
(I am a RoR noob)
And of course, does anyone see a much better way to do what I have
proposed?
My guess is that there is a much better way of approaching this. If
you have hundreds of different attributes, there is probably a much
simpler way of thinking about your data that will vastly simplify
things in the long run.
For example, if you have several different attributes denoting a value
in ‘mph’, ‘ft/s’, ‘m/s’, etc… it would be better to store the value as
a ‘value’ attribute and a ‘unit’ attribute.
A clearer explanation of exactly what you are trying to accomplish
would go a long way.
My guess is that there is a much better way of approaching this. If
you have hundreds of different attributes, there is probably a much
simpler way of thinking about your data that will vastly simplify
things in the long run.
The attributes in my models are wide and varied. They range from
tangential firing type, to cars per hour, to tonnes of pig manure. If I
was to create a column for each of them in the traditional manner I
would have hundreds of unique columns. I believe that by creating
generic float and string columns I can store this data in a compact
manner.
In my mind, the difference between this and a traditional STI is very
minimal. In my case, I simply repurpose the fields for different things
across sub classes. At the end of the day the type column will let me
know what subclass I am working with.
For example, if you have several different attributes denoting a value
in ‘mph’, ‘ft/s’, ‘m/s’, etc… it would be better to store the value as
a ‘value’ attribute and a ‘unit’ attribute.
This is essentially what I am doing except without the unit attribute,
which I think is a grand idea. I could have a column named float1 and
then a column named float1_unit. That would make looking at the data in
the db more clear. Others I have spoken with have stressed the lack of
purity in the db schema I have proposed and have insisted that I will
end up hanging myself in the future because the db will be impenetrable
without my special decoder classes. However, the purity of hundreds
possibly thousands of tables with a few dozen rows each is not something
I relish.
I suppose another way to handle it would be to use a one-to-many
relationship.
object has_many :attributes
Where an attribute is defined as
name : string => ‘tons of manure’
attr_type : string => [‘string’,‘integer’,‘float’, ‘datetime’]
attr_svalue :string => string representation of value
attr_nvalue :float => numeric representation of value
then set up a class for the attributes to handle the type conversions
if necessary… this could be polymorphic aware.
If you are interested in units, the ‘ruby-units’ gem can be used to
handle units in a rails app. You just save the unit value as a string,
and cast it to a unit when you retrieve it and you can then do normal
unit transformations and math with it.
_Kevin
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.