On Mar 3, 4:42 pm, Yoram <[email protected]> wrote: > I'm staying away from STI because I want to be able to add additional > asset types over time, none of which share attributes with other > assets. So - with STI, I could end up with a table that has hundreds > of columns.
And this is a problem because...? Sounds an awful lot like premature optimization. This sort of thing is not supported well by Rails, as it's tricky to handle in general (after all, one could create additional subclasses of Asset on-the-fly so Rails can't be sure which tables it should be querying) and even if possible wouldn't support some operations cleanly - imagine trying to paginate the assets association... One thought was using a join model with a polymorphic belongs_to and has_many :through, but that won't work either: http://stackoverflow.com/questions/1683265/activerecord-has-many-through-and-polymorphic-associations One thing that *might* work would be to have a model that holds the common attributes that then belongs_to the specific types. Not optimal, but might work with some usage patterns. I'm assuming the models you're using are generic examples and not the real models, so I'll skip addressing the fact that there are very few operations / actions that make sense applied to both 'Chair' and 'Teacher'. Even including both in a single list would seem pretty peculiar. --Matt Jones -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
