I am using Rails 3.
The main model is Product
:product has_many :images
:product has_many :related_products (self-referential)
:product has_many :descriptions
:product has_many :specifications
:product has_many :upc_codes
:product has_many :prices
You get the idea. I'm trying to determ开发者_运维知识库ine if I can shoehorn this into a properties model, where a property be a price, specification, description, etc. But the problem I run into there is that while some of these child models have only one attribute, others have many. For example, an Image may just have a path attribute, but a Description can have a text value and language code, and a Price can have the price and a currency component.
The Properties model offers lots of flexibility, but it breaks down if I am dealing with a child attribute containing more than one attribute.
Is the real answer that I need both of these? The Properties way for attributes that are always one-to-one with a product, and each of these individual models (Price, Description, etc.) for those child models that have multiple attributes?
If the properties have a very similar set of methods, use cases and behaviours, it would make sense to merge them into a single Property model.
If they each work in different ways, requiring different methods and behaviours, then what you currently describe would be correct.
If the situation is somewhere between the two, you could use Single Table Inheritance to avoid code duplication, and keep the design simple.
精彩评论