What approach for Commerce products, attributes and product displays?

Question

I am building a site, based on Commerce Kickstart. At this moment the site will not have a store, but it's on the horizon and I am trying to prepare the site beforehand for a store launch with as little developer hassle as possible.

My concern is now to wisely design the products and their attributes.

First off, I have two taxonomies. One is obviously a Product tree. A Commerce Product will have only one term reference value possible. Then I have a Usage tree (or call it Applications), which describes how and where a product can be used. A Product Display will have multiple possible term references from that tree.

Now let's say, I have a brand of nails in different sizes: 1,2,3,4. The sizes 1 thru 3 would be tagged as "Home Use" and the size #4 - only as "Construction Use". All sizes would share some fields, such as main description, PDF attachments, images. And these could be fields on the Product level.

For sizes 1 thru 3, I would basically need one product display, speaking in terms of the page contents. And the Add to Cart button would have a list of models next to it: 1 thru 3. I would expect the button to add to cart SKUs mapped for each size.

For model #4 I would like to have perhaps additional set of images and a slightly different description, and the Add to Cart button would not need any select.

This is one possible approach. Another that comes to mind would be to treat all sizes as separate 4 product displays. Then, the Add to Cart buttons would have no attribute selector. This scenario could seem quite simple and obvious - a typical one-to-one relationship. However I am allergic to solutions that are not scalable, I hate cloning data as a slightest text correction would later require N edits on each product display.

So, which way would you go based on your experience? I don't know Commerce well enough but still want to be prepared for it beforehand.

I assume that SKU is something crucial for a successful and non-ambiguous order. But maybe my assumption is wrong.

I'm open for your insights.

Answer 1

When thinking about how to handle products and product displays, I prefer to model it after how Commerce Kickstart handles it's data organization:

Product displays are used to organize and present products to the customer and product entities are used to store product-specific information.

First off, I have two taxonomies. One is obviously a Product tree. A Commerce Product will have only one term reference value possible. Then I have a Usage tree (or call it Applications), which describes how and where a product can be used. A Product Display will have multiple possible term references from that tree.

Product catalog taxonomies influence how products are organized and subsequently found on your site. This would mean this information would go into the Product Display.

Now let's say, I have a brand of nails in different sizes: 1,2,3,4. The sizes 1 thru 3 would be tagged as "Home Use" and the size #4 - only as "Construction Use". All sizes would share some fields, such as main description, PDF attachments, images. And these could be fields on the Product level.

The "Use" field is a little tougher but I think you're on the right track. Anything that is specific to the individual SKU (product images, PDFs, diagrams, descriptions, sizes, etc.) would be on the product entity. You can still provide filtering using these attributes via Faceted search, but you end up not duplicating information across multiple entities.

I'm not sure how big your product catalog is, but there are some modules you can explore to ease your data management pain:

1. Inline Entity Forms: With IEF, you can create and manage product SKUs within your Product Displays. It makes 1:1 product relationships much easier to manage. It can also do 1:N relationships, but sharing those across multiple products can be painful with this.
2. The opposite of this is Commerce Auto Display, which allows you to create a Product display from within the Product entity form.

If you want to go down this road, IEF is preferred, since it tends to want you to keep only the SKU, price, and other bare minimum fields on the product entity.