I''m building a product catalogue, containing products and each product may have many articles. An article is a variation of the parent product, for instance in size, color, measurements, etc, depending on the kind of product. However, some products might not have articles, they''re just products without any variations. My questions concerns the model relationship between the product or article and the shopping cart (or cart item). The products with articles requires a has_many relationship with CartItem, but what about the products which have no articles? Should there also be a products has_many cart_items relationship, or perhaps the products with no articles should have a "invisible" implied article? Should I use STI to subclass CartItem into CartArticleItem and CartProductItem? Can you think of any other way to solve this problem? Best regards, Tomas Jogin
Tomas Jogin wrote:> I''m building a product catalogue, containing products and each product > may have many articles. An article is a variation of the parent > product, for instance in size, color, measurements, etc, depending on > the kind of product. >There is a way to model the product/item relationship which draws from the object oriented theory (I don''t remeber its name) which is used (not frequently) to support ERP systems: (I''m a bit simplifying) The product is the "model" or "class", it has properties ("attributes") which describe the variations inside the product domain: each combination of attribute values defines an item. Some of the attributes can be definied at the product level (their values defined) and are therefore inherited by all the items. E.g. a "tshirt" is a product, it has size and color as its attributes The items (articles) are "instances" of the product class which have all their attributes fixed to a certain value. Each article has a different part id (part number or SKU) which is the result of its class and attribute values. E.g. the "Red XL tshirt" is an item> However, some products might not have articles, they''re just products > without any variations. My questions concerns the model relationship > between the product or article and the shopping cart (or cart item). > The products with articles requires a has_many relationship with > CartItem, but what about the products which have no articles? Should > there also be a products has_many cart_items relationship, or perhaps > the products with no articles should have a "invisible" implied > article? Should I use STI to subclass CartItem into CartArticleItem > and CartProductItem? >What you will deliver to the custimer are actually articles (you never send "a tshirt", you''ll send "a Green M tshirt") BUT you may allow the customer to choose from a products catalog: he will just have to tell you the values of the attributes for the products he chooses, the coresponding articlewill go into the cart. So I see these relationships: - Product has_many Articles - Article belongs_to Product - Articles has_many CartItems - CartItem belongs_to Article you can go from product to cart item passing through the article N.B. the products with no attributes (or better with just product level attributes) will generate only one article, and that will be the one to go into the cart. HTH bye Luca Mearelli --
Interesting approach, but what if different products have wildly different attributes? And what if for instance Green T-shirts only come in small and medium, while Red T-shirts come in medium, large and extra large? This would be unlikely for a t-shirt, but the products our clients have can be complex in that kind of way. How is an article "generated"? Do you mean that the correct article is stored in the DB and looked up depending on the choices made by the visitor? Do you know somewhere I can read about the approach you describe? Regards, Tomas Jogin> There is a way to model the product/item relationship which draws from > the object oriented theory (I don''t remeber its name) which is used (not > frequently) to support ERP systems: (I''m a bit simplifying) > > The product is the "model" or "class", it has properties ("attributes") > which describe the variations inside the product domain: each > combination of attribute values defines an item. Some of the attributes > can be definied at the product level (their values defined) and are > therefore inherited by all the items. > E.g. a "tshirt" is a product, it has size and color as its attributes > > The items (articles) are "instances" of the product class which have all > their attributes fixed to a certain value. > Each article has a different part id (part number or SKU) which is the > result of its class and attribute values. > E.g. the "Red XL tshirt" is an item
Tomas Jogin wrote:> Interesting approach, but what if different products have wildly > different attributes? And what if for instance Green T-shirts only > come in small and medium, while Red T-shirts come in medium, large and > extra large? This would be unlikely for a t-shirt, but the products > our clients have can be complex in that kind of way. >You can have an Attribute entity, each one would have a certain set of values, Products have attributes and for each it is possible to define a variability field (that is which one of the values for that attribute are allowed for this product)> How is an article "generated"? Do you mean that the correct article is > stored in the DB and looked up depending on the choices made by the > visitor? >Yes an article should only hold a reference to the product and a list of attribute-value pairs.> Do you know somewhere I can read about the approach you describe? >Hmm, no I''ve learned this approach from the project manager at a previous job (we were actually developing an ERP software), but it actually is "just" object oriented analisys applied to a product definition (an configuration) domain (instead of software development) bye, Luca Mearelli