I am trying to decide between two different database architectures for an application to manage properties. For capturing the property features, I have two options: a single model/table with all the features as fields, or a set of joined models - property, feature, feature data. (see attached ERD diagram)
OPTION A Properties name address has_pool has_doorman has_etc. (a bunch of values, not all boolean) =OR= OPTION B Properties id name address Features id title featurable_type (polymorphic, in this case points to "property.id") data_type Feature_Data id feature_id featureable_id (polymorphic, in this case points to "property.id") My ingoing assumption is that we do not know all the features that can be associated with a property, and as time goes by new features will be requested by users and need to be added. Here is my question: is going to the hassle of joining two extra models just to make the features a bit more independent worth the difficulty of implementation versus just keeping everything in the main property model? Let's assume that this application will be scaled to a high level. Are there any performance issues associated with OPTION B that should be considered? Is there another way to model this data that makes more sense? Thanks in advance. Taylor Attachments: http://www.ruby-forum.com/attachment/4417/ERD_sample.png -- Posted via http://www.ruby-forum.com/. -- 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 rubyonrails-t...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
