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

Задача проста(?) как три копейки - структура базы каталога товаров. С реализацией вложенных категорий все понятно - 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.

MasterZivДа главный -то минус -- сложность написания запросов.
Решается их автоматической генерацией по метаданным.
И применением OLAP для аналитики (как завещал великий Тенцер).

Запросы как раз меньшее из зол :)

MasterZivПри чём тут сфинкс ? не понимаю...
Сфинкс как раз шаг в противоположную сторону. Ну разве что ноги пошире
расставить, чтобы стоять устойчиве...
Хотя с другой стороны действительно -- тот же OLAP/DSS/FACETS и т.п.

Я кстати сейчас Solr исследую на предмет Facet Browsing -- ничего так,
прикольно, быстро, хоть и на Java. В обзорах пишуть, что типа Sphinx -у
до них далеко ещё расти (сам не знаю, Sphinx не пользовал).

Сфинкс как и sorl позволяет сделать фасетный поиск(навигацию). Я использовал его на предыдущей работе - при грамотном использовании очень хороший инструмент.

MasterZivТипов атрибутов должно быть порядка 10.
Целое со знаком /без знака
дробное с фиксированной точкой
с плавающей
Дата, дата и время, время,
Деньги
( и кстати время-деньги :-)
строка,
текст,
бинарка

Ещё возможно тебе придётся реализовать какие-то домены из предметной области
этих товаров. Типа списки значений (emum)

Да, побольше 3 будет, согласен :)

MasterZivи ещё надо видимо сделать ссылки на другие объекты (товары), чтобы можно
было разные связи хранить.

Не очень понял зачем ссылки на другие объекты?

SERG1257Digital God Он вполне может быть решен через sphinx. Или sphinx не панацея от всего и вся? :)К сожалению, я не знаю, что такое сфинкс, предположу, что это система полнотекстового поиска. То бишь вы сводите задачу к ОДНОМУ полю у товара - ОПИСАЛОВО и натравливаете на него ваш сфинкс. Другие поля, теоретически, позволяют дофильтровать результат поиска, но практически вы никогда не знаете каким набором признаков обладает выбранная строка. То есть как оно будет реализовано - через EAV ли, или через XML да хоть через CSV от производителя, это не суть дела важно. Сразу вижу достоинство - пополнятелю базы важно только занести товар в правильную категорию (не надо сопоставлять поля описания производителя с вашей системой)

С определением сфинкса Вы не ошиблись - это система полнотекстового поиска. Но со сведением задачи к одному полю - ошибаетесь. Сфинкса можно натравить на модель EAV и он прекрасно будет работать, шустро вытаскивая данные :)

На тему пополнения базы - какую бы модель я не выбрал - реализовать удобное пополнение базы можно в любом случае. Будь то парсинг xml, csv или еще чего.

Бредятинаzeon11Ну, вот!
Хана топику!
Разумеется, потому что задача яйца выеденного не стоит. Хорошо, что Вы это так быстро поняли. На этот раз:)

Да нет, это он о mumps (к стати не нашел инфу по бд), couchdb и прочих...

БредятинаЕще раз повторю (не думаю, что автор топика умышленно игнорирует, просто не понял, скорее всего) - правильным решением является один объект (одна таблица) для этого одного типа сущности - Товара. Это эффективный способ организации данных, в сочетании с простым добавлением характеристик в процессе эксплуатации.

Вы правы, я не игнорирую. Просто не особо понял как работать с mumps и прочими базами в ключе моей задачи. То есть что будет одна сущность - Товар, я понимаю. Но как в этом случае работать с разными наборами параметров. Да еще так чтобы это работало и работало быстро - не очень въезжаю.

БредятинаDigital Godпропущено...


Вы правы, я не игнорирую. Просто не особо понял как работать с mumps и прочими базами в ключе моей задачи. То есть что будет одна сущность - Товар, я понимаю. Но как в этом случае работать с разными наборами параметров. Да еще так чтобы это работало и работало быстро - не очень въезжаю.
А это уже коммерческий вопрос. СУБД Вы, вероятно, не будете разрабатывать. Изучать технологию тоже вряд ли. Меня коммерческая составляющая не интересует, я только в техническом плане обсуждаю вопросы. Ваша задача легко решается специалистами, знакомыми с mumps. Причем, вариантов поддержки групп характеристик для товаров определенных классов существует несколько. Характеристик, скорее всего, у Вас будет всего лишь несколько тысяч. Примерно (идентификатор - название):
1 - Наименование
2 - Длина, мм
...
817 - Сопротивление, Ом
...
1344 - Объем, м куб.

Данные будут храниться компактно. Например, данные об одном конкретном товаре с идентификатором 1345601, относящемся к классу, для которого определены характеристики 1,13,138,1209, будут храниться так:
^T(1345601,1)=Яблоко
^(13)=34
^(138)=3.78
^(1209)=6
Ничего лишнего:)
Вооружившись такими минимальными знаниями, Вы можете спокойно продолжать реализовывать EAV в какой-нибудь реляционной системе, так как она распространенная и по ней есть специалисты:) То есть, вернетесь к коммерческой составляющей инженерного решения. Это нормально. Но не знать о технологиях БД, все-таки, нехорошо, если Вы разрабатываете приложение БД.

Просто про Ваш mumps я что-то в интернете мало чего нашел, поэтому смутно представляю что это. Знания в проектировании у меня есть - просто я уже 5 лет поддерживаю и развиваю БД в банке и новых веяний в моделях для создания каталога не знаю - не интересовался просто.

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

Бредятина,
может стоит рассмотреть комбинированный вариант - типа mysql+mongo(couch и т.д.) или лучше не мудрить?