Всем првет.
Делаю магаз, аналогичный яндекс-маркету, но, естественно, значительно меньше.
Суть как и на меркете: в списке выводятся товары с названием, описанием и средней ценой. При этом, если один и тот же товар продают 10 магазинов, выводится все равно 1 товар, а цена выводится как средняя среди цен всех магазинов, продающий данный товар.

На странице просмотра товара также отображаются общие х-ки конкретного товара, а не в каждом магазине выводятся свои. Поэтому возник вопрос в правильной разработке структуры БД. Я решил следующее:

1. Таблица товаров (product). В ней содержатся общие х-ки товара (название, описание и т.д.). Эта таблица по сути дела является справочником, где товары не дублируются. Например, если добавляется товар, модель которого существут в данной таблице, он в нее не добавляется, а добавляется в таблицу shop_product (см. ниже).
2. Таблица магазинов (shop). В ней хранятся х-ки конкретного магазина (название магазина, адрес, телефон и т.д)
3. Таблица-мост товаров и магазинов (shop_product). Эта таблица связывает конкретный товар с конкретным магазином и хранит уже х-ки товара для конкретного магазина (например цена на данный товар в данном магазине, скидка, минимальная доставка и т.д.). Чтобы было более понятно: shop_product (id, prod_id, shop_id, price, discount, delivery_price ...). Надеюсь я понятно объяснил суть.

Теперь собственно вопросы:
1. Правильна ли идея хранить товары не в дублированном виде в соответствие с требованиями? Я говорю про справочник из п.1.
2. Самый главный вопрос. У товара есть категории (фото, бытовая техника и т.д) и в зависимости от категории перечень характеристик будет разный (например, для фото - там брекетинг, фокусное расстояние, для одежды - тип ткани, размеры и тд). Как быть тут? Я вижу 2 способа, но ни 1 мне не нравится.

Способ 1. На каждую категорию создавать отдельную таблицу товаров (product_photo, product_clothes ...). При такой структуре проблем с хранением х-к нет. Только есть другая проблема: если добавляется новая категория (что, я думаю, будет довольно редко) придется создавать новую таблицу в БД + допрограмливать. Иными словами такая структура будет требовать наличия программиста.

Способ 2. Специфические (зависимые от категории х-ки) хранить в отдельной таблице в виде пары "название х-ки"-"значение х-ки" с привязкой к конкретному товару: product_characteristic (id, product_id, title, value). И соответственно в приложении, когда добавляется товар, сделать возможность добавления бесконечного числа х-к, путем нажатия на кнопочку плюс. Юзер на нее нажимает и ниже добавляется блок из двух полей с названием и значением х-ки. Это универсальная штука, но тут представьте, до какого размера может разрастить эта таблица. Если товаров скажем будет 10 000, и по каждому 50 х-к, это уже полляма записей. А товаров будет значительно больше со временем? Вот поэтому мне этот вариант и не нравится.

Есть ли кто-нибудь, кто сталкивался с аналогичной задачей? Я буду благодарен вам за совет и помощь!