Необходимо создать максимально широкий каталог для самых разных товаров в универмаге. Одновременно могут продаваться и эмалированные ведра, и авторучки и автомобили. Необходимо разработать структуру хранения и поиска по параметрам. Параметры могут быть от объема двигателя и цвета, до производителя и запаха (напр. для одеколона). Каталог должен быть легко расширяем как по созданию новых типов товаров, так и в отношении добавления новых параметров уже существующих. Может кто сталкивался с подобной задачей?\r
Пока есть такие варианты:\r
1) Создается мегатаблица вида:\r
id | type | color | country | mfgr | date | ...| параметрN | параметрN+1 и т.д.\r
то есть, перечисляем в колонках все виды параметров (часть из них будет собственно данными - цена, год и т.д, а часть ссылками на другие таблицы - например, производитель, цвет и тп.), которые есть в системе. Занося инфо о новом товаре, мы заполняем только нужные поля, остальные оставляем NULL.\r
2) Набор отдельных табличек для каждого типа товара и таблица связка, раскрывающая что каждый тип обозначает. Тогда к каждой таблице можно приписать только определенные параметры, и никто не сможет ввести для пачки сигарет октановость, или крепость для бензопилы. Но как быть с цветами предметов? Например, диапазон цветов автомобилей и вина различается кардинально. Не заводить же отдельно таблицы цвета_вин, цвета_авто и др. Значит, проблема контроля вводимых значений остается. И опять же что такое тип товара? Навреняка будет немало товаров очень похоих друг на друга по возможным параметрам - значит, разделение несколько условно.\r
3) Вариант фиксированного количества таблиц и записи параметров не по горизонтали и по вертикали, то что активно обсуждалось в теме про больных у каждого из которых может быть от 10 до 124 параметров. /topic/70514\r
\r
Т.е. примерно такая структура:\r
Табл 1: Справочник типы товаров:\r
- номер типа\r
- название\r
- ссылка на родительский тип (если нужно сделать какое-то подобие иерархичности)\r
Данные: \r
№ строки -- название -- ссылка\r
1 -- сигареты -- 0\r
2 -- вино -- 0\r
3 -- авторучки --0\r
\r
Табл 2: Справочник типы параметров:\r
- номер параметра\r
- название\r
№ -- название \r
1 -- крепость\r
2 -- производитель\r
3 -- форма бутылки\r
4 -- количество в упаковке\r
5 -- материал\r
6 -- позолочено?\r
\r
Табл 3: Сами товары. Ммеет следующий вид\r
№ строки -- № типа товара -- тип параметра -- значение \r
1 -- 1 -- 2 -- 15%\r
2 -- 1 -- 4 -- 20\r
3 -- 3 -- 5 -- золото\r
и так далее.\r
Я уже высказывал в той теме, что нужно хранить не сами значения, а ссылки на них. Т.е. база обогащается таблицами "материал", "производитель", "страна", "цена" и т.п. \r
А где хранить название и другие уникальные вещи, например, крепость?\r
Получается, их тоже нужно вынести в отдельную таблицу и делать ссылки 1:1.\r
Кто что думает по этому поводу?

2Серега:
если большой каталог, то у клиента возникает потребность в различных выборках. На примере тех же фотоаппаратов: человек может не разбираться каая марка лучше или хуже, что ему нужно Сони или Олимпус. Но может твердо знать, что он хочет зеркалку с таким -то зумом, или в таком-то ценовом диапазоне.

2Petr Chulkov
Т.е. в значениях свойств ты хранишь несколько типо в колонок и из них используется только одна, которая указана в описании самого типа?
По поводу иерархии в каталоге, т.е. есть типы-ветки, а есть конкретные позиции-листья? И листья могут иметь лишь те типы параметры, что приписаны для родительских элементов? Это экономит лишнюю таблицу, позволяет сделать наследование, но усложняет работу - начинается какой-то иерерхо-объектный подход. Или я тебя не правильно понял?
Кстати, тут есть спецы по иерархическим или объектым базам?
как там решить эту задачу?