Had a random quick question just because I'm curious. Why do parent product records _`spree_products.id`_ exist in the _`spree_variants`_ table. Meaning if a product has no variants it exists 1x in

spree_variants

but if it has variants it exists more than 1 time. Why wouldn't the parent product row just never exist in

spree_variants

until it actually has a variant. In similar behaviors as other data tables work such as kits.

Not entirely sure, but from dealing with the data a bit, I would guess that it's because there are some fields that are associated with variants (sku, weight, length, etc) that aren't in the product table

every product has 1 main variant, always. So for every variant there is a relationship with the product. For every variant we need to keep a foreign key to the product it belongs to

Yeah, the master variant records some variant-y stuff for products that don't have variants. Consider prices (but this extends to most data associated with variants): • For a product with multiple variants, they all need prices • For a product with "no variants" (a single purchasable SKU), it still needs prices Having a master variant gives us: • For a product with multiple variants, a place to store the "default price" (the price that might show on a product listing page or a product display page before the customer selects a particular variant) • For a product with "no variants" (a single purchasable SKU), it gives us a place to store the purchase price for that SKU All of this means that prices are always associated with variants, not variants and products. This is a little unintuitive, but in the end it makes the system a little more flexible while avoiding the complexity of a polymorphic association.

Thanks for the follow up. I should I guess have said I do understand why it has to at the moment especially around stored values like price and everything else using variant_id . More so was just thinking why not keeping all products in the variants table and following a relation similar to how spree_product_assemblies works where you could just reference variants in another table being assigned to a parent product. Or even defining a simple is_variant column similar to is_master where is_variant could just store the parent product id in the column and anything null would be a non variant For example since most pivots off of variant_id when you want to change another value in the spree_products table what I find is you need to look to see a count of that product_id in the spree_variants table. Anything with count of 1 would be a non variant spree_product.id in the spree_products table and anything >1 would be a parent product of which has variants.

From the data side of things, that seems like it would lead to either a lot of duplicated data or unnecessary fields (if I understand you correctly). If you have a product with 20 variants, you'd end up duplicating all the general product information on each variant. Or you'd have the data only on the master and a bunch of empty fields on the variants. The products table exists to keep that data that's shared across all variants, and the variants table is for the data that's unique to each version of it.