views:

28

answers:

1

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 determine 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?

+1  A: 

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.

DanSingerman
That was the key, Dan. I was focusing on the attributes themselves rather than the behaviors. The behaviors determine whether or not something is an entity, thanks for the answer.
AKWF