Espero que el título sea algo útil. Estoy usando MySQL como mi base de datos

Estoy creando una base de datos de productos y no estoy seguro de cómo manejar los precios de almacenamiento / SKU de las variaciones de un producto. Un producto puede tener variaciones ilimitadas, y cada combinación de variación tiene su propio precio / SKU / etc.

Así es como tengo mi tabla de productos / variaciones configurada en este momento:

PRODUCTS
+--------------------------+
| id | name | description  |
+----+------+--------------+
| 1  | rug  | a cool rug   |
| 2  | cup  | a coffee cup |
+----+------+--------------+

PRODUCT_VARIANTS
+----+------------+----------+-----------+
| id | product_id | variant  | value     |
+----+------------+----------+-----------+
| 1  | 1          | color    | red       |
| 2  | 1          | color    | blue      |
| 3  | 1          | color    | green     |
| 4  | 1          | material | wool      |
| 5  | 1          | material | polyester |
| 6  | 2          | size     | small     |
| 7  | 2          | size     | medium    |
| 8  | 2          | size     | large     |
+----+------------+----------+-----------+

(`products.id` is a foreign key of `product_variants.product_id`)

He creado un SQLFiddle con estos datos de muestra:http://sqlfiddle.com/#!2/2264d/1

El usuario puede introducir cualquier nombre de variación (product_variants.variant) y puede asignarle cualquier valor (product_variants.value).No debe haber un límite en la cantidad de variaciones / valores que un usuario puede ingresar.

Aquí es donde surge mi problema: almacenar precios / SKU para cada variación sin agregar una nueva tabla / columna cada vez que alguien agrega un producto con una variante que no existía antes.

Cada variante puede tener el mismo precio, pero el SKU es único para cada producto. Por ejemplo producto1 tiene 6 combinaciones diferentes (3 colores * 2 materiales) y Producto2 Solo tiene 3 combinaciones diferentes (3 tamaños * 1).

He pensado en almacenar las combinaciones como un texto, es decir:

+------------+-----------------+-------+------+
| product_id | combination     | price | SKU  |
+------------+-----------------+-------+------+
| 1          | red-wool        | 50.00 | A121 |
| 1          | red-polyester   | 50.00 | A122 |
| 1          | blue-wool       | 50.00 | A123 |
| 1          | blue-polyester  | 50.00 | A124 |
| 1          | green-wool      | 50.00 | A125 |
| 1          | green-polyester | 50.00 | A125 |
| 2          | small           | 4.00  | CD12 |
| 2          | medium          | 4.00  | CD13 |
| 2          | large           | 3.50  | CD14 |
+------------+-----------------+-------+------+

Pero debe haber una forma mejor, normalizada, de representar estos datos. Situación hipotética: quiero poder buscar un producto azul que sea menos de $ 10. Con la estructura de base de datos anterior no es posible hacerlo sin analizar el texto y eso es algo que quiero evitar.

Cualquier ayuda / sugerencias son apreciadas =)