Здравствуйте. Начал писать приложение для магазина и понял, что не могу сделать БД. Либо задача все-таки нестандартная либо у меня навыков нет, но прошу помочь советом.
В общем интернет-магазин. Закупает товары у нескольких поставщиков. Это "внешние", т.е. исходные товары. Продавать именно их неудобно. Нужно создать продукты на основе этих товаров:
а) Прямое соответствие;
б) Разбиение на опции (у поставщика много вариаций товара, но он идет как один и под одним артикулом, а магазину нужно выделить эти вариации и предложить их в качестве опций продукта);
в) Объединение товаров в качестве опций (у поставщика имеются однотипные товары. Чтобы не засорять витрину их нужно объединить под одним продуктом, а вариации будут доступны в качестве опций);
г) Создание комплексных товаров (из нескольких товаров собрать один продукт).
При этом:
- Для всех товаров нужно вести учет - сколько чего осталось;
- Магазин держит очень маленький склад и преимущественно торгует под заказ. Поэтому схема, когда сначала закупили, завели приход, а у себя уже ведут базу со своими продуктами не подходит. Нужно организовать соответствие и учет именно в товарах поставщиков.

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

Мне приходит в голову такое решение, что нужно составлять каскад соответствий ПРОДУКТЫ_ДЛЯ ПРОДАЖИ <-> СУЩНОСТИ_ЛОКАЛЬНОГО_СКЛАДА <-> ТОВАРЫ_ПОСТАВЩИКОВ.
Сейчас я пытаюсь делать так: в таблице исходных товаров, если для товара есть опии, создаю полные дубликаты записей, которые различаются только значением поля option.

Все это некрасиво и неудобно. Можете ли что-нибудь посоветовать?

Не знаю как подробнее.
Я не говорил ничего про производство.
Учет только такой: наличие у поставщика, наличие на своем складе, закупочная стоимость, соответствие продукта исходному товару(ам).

Сама ситуация такая, что магазин торгует почти только по факту совершения заказа: поступил заказ, едет к поставщику на склад и покупает товар. Сейчас существует одна единственная таблица товаров - что покупают у поставщиков, то и продают. Скрипты парсят наличие с сайтов поставщиков и проставляют наличие в БД магазина. Если в магазине остались какие-то товары, то хранится количество, которое осталось. Ну и хранится закупочная стоимость.
Заказ забрали, бухгалтеру отправилась отгрузка - такие-то артикулы в таком-то количестве. Через месяц приходит возврат заказа №такой-то - соответственно эти товары появляются на собственном складе. Вот, вроде, вся логика.

Нужно же предлагать товары не как есть, а так сказать "упаковывать" по своему: собирать из нескольких товаров один (комплексный), собирать товары под одним (опции), дробить товар на разновидности (виртуальные, что-ли, опции).

mad_nazgulА так у Вас должно быть две сущности:
1) Приобретаемые товары
2) Отпускаемые товары
И матрица соответствия м/у ними.

В этом и проблема. Когда приобретаемый товар "дробится" на опции, то появляются как-бы новые товары, производные от сущности приобретаемого товара. Например, карандаши - зеленые, желтые, красные - идут у поставщика как один товар, без различий цвета. "Раздробить" значит выделить эти цвета.

И я написал, что мне приходит в голову либо каскад соответствий ПРОДУКТЫ_ДЛЯ ПРОДАЖИ <-> СУЩНОСТИ_ЛОКАЛЬНОГО_СКЛАДА <-> ТОВАРЫ_ПОСТАВЩИКОВ. Где "сущности локального склада" это товары поставщиков, прошедшие через фильтр (т.е. уже были раздроблены, если нужно, или остались без изменений).
Но мне такая схема не нравится и я просто дублирую записи в таблице приобретаемых товаров, если нужно товар "раздробить".

ViPRos,
Чуть-чуть уточните, пожалуйста, что гуглить? Только поконкретнее, если можно.

Кто-нибудь может сказать, что это такое:
авторклассификатор
1. по свойствам
2. агрегирующий