Как бы вами реализовалось следующее?
Есть торговая сеть. В ней продается большой ассортимент продукции. Этот ассортимет постоянно пополняется - появляются новые виды товаров. Все эти товары имеют ряд одинаковых свойств и ряд отличающихся, предположим, для каждой ассортиментной группы. Причем большинство отличающихся свойств, могут быть неизвестны в момент проектирования БД. Как споектировать БД с учетом возможности расширения свойств товара, а также учетом дальнейшей обработки и производительности. Сейчас есть три подхода:
1. есть справочник товаров(idтовара, ассортиментная группа, название), есть справочники для расширения свойств, например для одних товаров (idтовара, свойство1, свойство2), для других товаров (idтовара, свойство100, свойство101) и т.д. Связь между справочником товаров и этими справочниками 1..1. то-есть для каждого нового вида товара будут добавляться новые справочники
2.есть справочник товаров(idтовара, ассортиментная группа, название, свойство1, сойство2,..свойство10), есть справочник свойств (idсвойства, idассортиментной группы, указатель на поле свойства из справочника товаров)
то-есть в указанныз 10 полях свойств могут быть различные свойства для различныз ассортиментных групп.
3.есть справочник товаров(idтовара, ассортиментная группа, название, свойствА). В поле свойствА - зашифрованный номер свойств. Это может быть текстовое поле, скажем 200 символов. В каждых, предположим, двух разрядах относительная позиция свойства в таблице свойств. Таким образом описывается 200/2=100 свойств. Таблица свойств - древовидная таблица (idсовйства, idparentсвойства,idассортиментной группы,название свойства)

Programmer_OrtodoxНу сделали,допустим,этот справочник, а дальше что? К чему он прикладываться будет?
Уже существует система, к которой все приложено. Поэтому я сосредоточил внимание только на отдельных сущностях. Мой вопрос заключается в том, как наиболее эффективней разработать структуру данных. есть три предложенных варианта, которые прошу обсудить, или можно предложить альтернативные.

Petr Chulkovя пару месяцев назад на одном из форумов данного сайта рассказывал о том, как такое делать.. там спрашивали о том. как сделать возможность учёта свойств товаров как на market.yandex.ru .... воспользуйтесь поиском.. будут вопросы - wellcome...

С уважением,
Petr[@]Chulkov.NET

Спасибо, нашел /topic/276752

Petr Chulkov
всё просто..
делаем пару справочников
1. справочник номенклатур (ключ, название и прочие св-ва, общие для всех номенклатур)
2. справочник характеристик (ключ, название, тип, № п.п.)
3. справочиние отношений номенклатур и характеристик ( код номенкл., код хар-ки, № п.п.)
4. собственно значения св-тв....
( код номенкл., код хар-ки, значение строка, значение дата, значение логическое и т.д.)


Все прекрасно, на бумаге выглядит гладко. Но приходится брать во внимание действительность. На практике имеется более 1 000 000 позиций товаров. Для каждого из этих товаров есть минимум четыре различных свойства. Это будет раздувать таблицу 4 по крайней мере раза в 4 по отношению к количеству товаров. Как вы считаете, это скажется на проиводительности запросов?

Petr Chulkov

1M - это товаров... а групп (номенклатурных групп \ товарных групп - как угодно можно назвать ) там - ну 0.5К.. не более... (иначе никто ничего не найдёт..)
вот на эти группы и вешайте свойства ...

Повторюсь - есть уже работающая система(БД Oracle). В ней, возможно, не совсем удачно споетирована БД. на данном этапе сократить так или иначе количество товаров не полчиться. В то-же время появляются новые характеристики и , что приводит к постоянным изменениям. В данном случае это подход изложенный мной под номером один. Возможны другие подходы. Некоторые из них изложил я, также предложили подход и вы. При этом подходе свойства действительно описаны для групп, а вот конечные значения храняться в отдельной таблице. При этом количество записей в ней будет количество товаров(а не групп)*количество свойств.

Petro123Есть торговая сеть.
====== 2 палатки?

В ней продается большой ассортимент продукции.
========= 1 000 000 наименований?

Этот ассортимет постоянно пополняется - появляются новые виды товаров.
======== "сколько граммов" в день?

вопрос - потянет ли Oracl - в "Сравнение СУБД" IMHO [/quot]
порядка 30 территориально распределенных торговых комплекса. в каждом от 10 до 50 касс, необходимо учитывать и других пользователей системы(менеджеры, склады и т.д.)
Вопроса в сравнении БД нет - есть одна, Oracle. Вопрос в методах представления данных и эффективности работы с ними.

А при каких обстоятельствах вы стали бы применять 3 вариант? И стали бы вообще?

ModelRЕсли бы меня совершенно не касались вопросы, как с этими данными будут работать запросы и большую платили премию за небольшую экономию дисковой памяти:).

Кстати, в только 3 варианте упоминатеся иерахия свойств. Почему?

предположим у меня есть справочник групп товаров. для каждой из этих групп есть свои свойства. рассмотрим группу В. Предположим у нее есть такие свойства размер, цвет. Размер - 1,2..99 Цвет-красный, белый,черный. Вот и иерархия. Стоит учесть, что при классификации свойств потребуется углубляться и дальше(не линейно).
А можно ли предположить, что здесь будет не только экономия места? Допустим полученное значение я использую в виде штрих кода. То-есть имея просто товар с таким кодом и классификатор я быстро определю свойства товара.