Всем доброго времени суток!
Никогда раньше не занимался проектированием базы для крупных проектов, поэтому столкнулся с проблемой выбора структуры бд.

Задача проста(?) как три копейки - структура базы каталога товаров. С реализацией вложенных категорий все понятно - nested sets (или уже придумали что-то получше?).

Вопрос в хранении товаров и их характеристик. Кол-во товаров несколько миллионов, кол-во характеристик к каждому из них - от 20 до 100 (а может и больше). Из функционала ничего сверхъестественного - поиск, вставка, сравнение товаров, поиск схожих.

Наиболее реальной кажется такая структура:

Справочник
id
название

Значения справочника
id
id справочника
Название

Параметры
Id
id категории
название параметра
тип параметра (строка, число, дата, список)
id справочника

Товар
id
id категории
название, цена и прочее

параметры товаров
id
id параметра
id товара
значение

Насколько удачно такое решение? В плане скорости выборок (вывод категории, поиск по параметрам)?

SERG1257В двух словах - хорошо для начала, хуже потом, очень плохо, когда проект разрастется
Я конечно догадывался, что с ростом базы товаров, все это дело просядет. А какие еще есть варианты кроме EAV?

SERG1257По поводу деревьев - http://www.osp.ru/pcworld/2007/03/4199032/
Спасибо, почитаю

alexeyvg1. таблица с набором полей - Param1...ParamN
Думаю этот вариант отпадает сразу. с учетом уникальности набора параметром, пусть даже только для группы продуктов, получится очень много таблиц.

alexeyvg2. с отдельными таблицами для каждого набора параметров (то есть учитывая тот факт, что набор параметров уникален не для каждого товара, а для каких то групп товаров, и в принципе таких уникальных наборов будет не так много).
Но тут важно, как будут использоваться эти параметры, будет поиск по параметру только в одной группе товаров или среди всех товаров.
3. Да, ещё один вариант: Набор параметров кладут в одно поле (допустим, xml). Можно использовать, если нет поиска по параметрам.
Мне кажется что для обоих вариантов в качестве поиска подойдет Sphinx (грамотно настроенный). По сути это будет отличным решением для поиска и вывода схожих продуктов. Для сокращения накладок ограничимся поиском по этой же категории.

Интересно, как яндекс маркет хранит данные?

sp,
По сути конкретика не нужна - нужно понять направление в котором двигаться. Сюда я обратился, чтобы узнать мнение людей какую модель стоит использовать и не придумали что-то новое.

guest_20040621,
Я не прошу ни кого за меня что-то делать. Форум называется проектирование бд я и задал вопрос - по какой модели лучше делать базу для каталога.

Прошу прощения, на работе не было возможности нормально ответить на вопросы.

Dimitry SibiryakovDigital Godя и задал вопрос - по какой модели лучше делать базу для каталога.

И получил ответ: EAV - единственная работоспособная модель.

как видно из рассуждений - не только EAV подходит, но в целом обобщенный ответ я получил.

guest_20040621 Вы критерий "лучшести" сформулировать забыли. Хотите тяп-ляп, быстро и одноразово - это EAV. Хотите, чтобы ваша база данных имела нормальный жизненный цикл, - забудьте про EAV как про страшный сон.
Мне кажется в таком вопросе критерий "лучшести" очевиден - скорость работы, и как правильно заметил SERG1257 - каталог товаров это система с редкой записью по сравнению с выборками. Значит упор на качество и скорость выборок.

guest_20040621 То, что вы назвали "каталог товаров" - одна из наиболее трудоемких задач для проектирования. Нет ни одной реализации, которую можно было бы считать удовлетворительной. Начинать учиться проектированию лучше с задач попроще.
Не вижу ничего трудоемкого в данной задаче. Есть модели проектирования со своими плюсами и минусами. Надо выбрать одну и постараться компенсировать ее минусы через какие-то методы (поиск через sphinx, грамотное индексирование, в конце концов - масштабируемость ресурсов сервера). Понятное дело что из-за специфики проекта будут свои тонкости в реализации - в целом задача достаточна простая.

MasterZivКстати, RDF можно было бы использовать для этого (оно конечно -- тот же почти
EAV, только вид сбоку, но там полиморфизм атрибутов изначально заложен в модель
данных).

Каюсь, про RDF не знаю ничего. На днях обязательно почитаю и поищу примеры реализации.

MasterZivПоиск схожих достаточноможет быть сложным.

Он вполне может быть решен через sphinx. Или sphinx не панацея от всего и вся? :)

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

MasterZivDigital God,
У тебя в некоторых таблицах лишние суррогатное ключи (ид), убирай где не нужно. Например,в параметрах товара.
2) параметры разных типов надо хранить в разных таблицах или в разных полях одной таблицы. Иначе и индексировать плохо, и нарушение доменной целостности может быть.

1) Я просто писал пример на скорую руку, конечно ничего лишнего в конечном результате не будет.
2) согласен. поскольку типов данных не так много (строка, число и дата) - можно обойтись 3 таблицами.

Dimitry SibiryakovDigital Godкак видно из рассуждений - не только EAV подходит

Очевидно, мне нужно было выделить слово "работоспособная" жирным крупным шрифтом... Но кто
я такой, чтобы охранять Ваши яйца от граблей?..

Никто не отрицал EAV, просто рассматриваем варианты реализация и все за и против.

alexeyvgDigital GodИнтересно, как яндекс маркет хранит данные?EAV используют.
Я делал (не один, конечно) проект Подбери.ру, его купил яндекс и так появился яндекс маркет :-)
Конечно, наверняка код они за эти 10 лет переписали, но вряд ли принцип поменялся.
Я где-то так и думал что это EAV с модификациями.

В общем буду развивать тему EAV.