Примерно так мне и подумалось. Характеристик у товара может быть неопределенное кол-во, я буду хранить сущность самого товара в json формате рядом с этим составным своим id-шником. И вытягивая, буду иметь под рукой сразу все данные о товаре в одном флаконе. Останется только взять текущую цену и проверить наличие на складе, а они всегда в одной таблице.
Ответила в предыдущем комменте. Размер - родительская характеристика, цвет - дочерняя. Если артикул один - будет один товар в БД таблице products, а на странице собираться с учетом всех характеристик, включая изменение по цене.
У меня так задумано, что характеристики могут быть нескольких типов, например - зависимые. Так цвет зависит от размера и ботинки 45 размера красного цвета могут отличаться по цене от ботинков 41 размера черного цвета той же самой модели. То есть реализована связь - родитель-ребенок-цена, кол-во.
Другая таблица характеристик заточена на то, что виски Red Lable объемом 0,5л, 0,7л и 1л. продается по разной цене. Соответственно таблица уже иная, без родительской взаимосвязи характеристик. Она вообще может не зависеть от цены и включать выборку товара по гендеру.
Я пыталась сделать по-правильному одну таблицу, но с моими хотелками это не вышло, пришлось делать 2 таблицы характеристик, отсюда - составной id конкретного товара. Зато обеспечена максимальная гибкость.