Наверное моя проблема стара, и скорее всего она EAV, но все же я спрошу.
Итак, задача - в интернет магазине есть товары, у этих товаров есть свойства. По этим свойствам происходит фильтрация. Проблема в том, что заказчик хочет иметь возможность добавлять новый тип товара со своим набором свойств (допустим будет форма "создать тип товара с набором характеристик").
Допустим, он торговал сотовыми телефонами и вдруг решил торговать, ну допустим, картошкой  Понятно, что кроме названия, веса  и стоимости их мало что объединяет. В связи с этим возникает проблема хранения свойств и их добавления.

Варианты моего видения решения этой проблемы:
1) Есть 3 таблицы: объектов ,  таблица свойств объектов (номер объекта, идентификатор свойства, значение свойства), в которой одному объекту сопоставляется несколько свойств) есть таблица, ну и третья таблица - справочник свойств.

В принципе такая система имеет право на существование, но существенным недостатком такого подхода, думаю,  таблица свойств объектов (которая будет содержать на порядок больше записей чем объектов) и высокий риск нарушить целостность данных (мало ли изменится идентификатор объектов). И что будет с быстродействием?

2) Тут уже приходится модифицировать саму базу. Т.е. при создании нового типа товара, создается новая таблица объектов ( допустим таблица "картошка"), в которой будут содержаться объекты. Такой вариант вполне возможен, но если у объекта захотят изменить количество свойств? И это не одна проблема.

3) Хранение свойств, например, в XML. А как осуществлять фильтрацию объектов? А как работают с XML разне СУБД? Допустим, нужно посчитать количество картофелин диаметр которых > 5 см?

Еще раз повторюсь, может быть эта проблема не стояла бы так остро, если бы заказчик не хотел самостоятельно изменять и добавлять свойства. 

Поделитесь своим опытом в решении данной проблемы.

Я за данный вариант. Реализовывал подобным образом в одной информационной системе. Только вместо товаров были датчики различных производителей и типов, с различным набором характеристик.

??? Это же нарушение бизнес правил в ходе проектирования.

Проиндексировать и все будет в порядке. А если еще и кеш задействовать!

Все объекты БД должны быть созданы на этапе проектирования. Крайний случай.

Думаю, что нет.

Либо 1 либо 3 вариант, все зависит от СУБД (сможет ли она нормально работать с XML) и от конкретной задачи.

Например если будет что-то наподобие Яндекс.Маркета, где обмен данными идет в XML, то возможно 3 вариант будет предпочтительней. С другой стороны, если внутри приложения работа идет с объектами а не с XML, то не очень логично будет пред записью в БД перегонять данные в XML, а при чтении из БД парсить XML.

Вариант 1) Ты верно оценил риски. 
1.1)Самый большой риск - рассогласование данных. Однако справочник товаров весьма редко редактируется и уж тем более в многопользовательском режиме. Если ты сериализуешь доступ пользователей на редактирование по товару(один товар(и его аттрибуты) в один момент времени может изменять лишь один пользователь) и доступ на редактирование по свойству (справочник своейсв и свойство товаров в один момент времени может измеять лишь один пользователь.Особенно это касается свойств, значения которых задаются списком), думаю вполне можно будет избежать рассогласования, а вероятность дедлока бесконечно низка. Удаление товаров можно запретить(пользователь может помечать на удаление, удаление производится ночным батчем в монопольном режиме).
1.2) Производительность. Показать справочник товаров списком, со всеми определенными пользователями свойствами - практически не реально. Потому избавить пользователей от такой возможности - список определенных пользователем свойств показывать только для одного товара. Можно, конечно, сделать и динамическое формирование запроса, который будет формироваться в зависимости от списка свойств, который определил пользователь. Но контролировать план выполнения этого запроса на этапе проектирования нельзя, от того, лучше таки пользователя избавить от этой очевидно необходимой возможности.
1.3) Для того чтобы определяемое пользователем свойство влияло на бизнес логику приложения, необходима доработка приложения. В виду этого, организация хранения таким способом свойств возможна только для свойств, не влияющих на бизнес логику. Свойтсва же влияющие на бизнес логику лучше хранить способом 2). Как раз таки изза тогО, что определяемые пользователем свойства "ни на что" не влияют, еще очень велик риск, что пользователи будут весьма пофигистично относиться к ведению этих свойств, что очень обидно, ибо для реализации этой возможности придется затратить не мало каллорий.
Вариант 2) ИМХО Лучший вариант. Однако если заказчик не пробиваем - не канает ;)
Вариант 3) Разные СУБД с XML работают очень по разному. Если платформа БД не определена, думаю следует отказаться от этого варианта.

МОЕ ИМХО.
Любое стремление к универсальности - следствие недостаточного понимания конечных условий эксплуатации. Типа мы тут заложим возможность, а далее, додумаем. Любая же гибкость достигается потерей прочности. Я понимаю такое стремление у производителей тиражных продуктов. Разработчик заведомо не знает потребителя, оттого гибкость продукта расшираяет список потенциальных потребителей. Однако желания универсализации в индивидуальных решениях мне не понятно. Это дорого и не практично. 

Это сообщение отредактировал(а) Zloxa - 10.7.2009, 12:56

Уважаемый Zloxa!
В большей степени я с Вами согласен. Однако, в своей практике, я пару раз сталкивался с ситуацией, когда заказчик говорит, что у него сейчас нет таких данных, но, возможно, они появятся в будущем и их нужно будет вносить или появятся другие данные и потребуется реструктуризация. И тут приходится искать компромисс между универсальностью/гибкостью и  "потерей прочности".

И как ты предлагаешь реализовывать что нибудь наподобие Яндекс.Маркета?

Да, прошу прощения, забываю, что помимо ЕРП, бывают еще и ЕШопы ;)
Для чего нить "на поподбие", Метод 1 таки предпочтительнее по причинам:
1) Изменение схемы данных(реализация способом 2) требует прекращения обслуживания пользователей. Пусть кратковременного, но все равно может нанести имиджевый ущерб.
2) На сколько я понял, там нет проблемы конкурентной модификации атрибутов справочника, партнеры скорее всего выставляются в оговоренном формате, а накат данных производится по регламенту, исключающему рассогласование данных, т.е. самый основной риск(1.1) здесь полностью вырожден.

UPD.
Однако, все же, "Чтото вроде" Яндыкс-Маркета, это скорее исключение нежели правило. По кр. мере я намного чаще встречаюсь с ситуацией, когда нагороженный огород против alter table add column не имеет приемуществ, лишь недостатки.

UPD2
Полазив еще по указанному ресурсу, пришел к выводу, что отнюдь не факт что "звуковые карты" и "видоекарты" это суть одна таблица. По крайней мере ни одного представления, где комплектующие шли бы в одном списке (за исключением результата fulltext поиска) где можно было бы отобрать одновременно и звуковухи и видюхи, по общему набору аттрибутов, я не нашел. Ну и в чем тогда целесообразность объединения их в одну сущность с гибким набором атрибутов?

Это сообщение отредактировал(а) Zloxa - 13.7.2009, 23:26

1. Я говорил исключительно про:


2. Ты же понимаешь, что за DDL в продакшн базе дба бъют сильно и больно  
И если Яндекс может себе позволить содержать штат админов, которые на каждую новую категорию будут создавать таблицу, добавлять поле и т.п. То большинство компаний - нет.

И это достаточное основания отказаться от словаря метаданных СУБД и городить свой огород, который изначально будет выполнять те же функции только заметно хуже?

Хочуны заказчкиов, это основание ;) И в этом контексте EAV это компромиссное решение, не правильное.

Он:
1. проще
2. ориентирован на конкретную задачу, а значит справляется с ней лучше
3. транзакционен и поддерживается механизмами обеспечения целостности СУБД

Чтото у меня складывается ощущение что мы говорим с тобой о разных вещах. Ибо все три перечисленных тобой пункта, с моей точки зрения - преимущества alter table 

Я говорю об Определяемых Пользователем Атрибутах (User Defined Attributes).
1) Реализация конкурентной модификации справочника и UDA - задача весьма не тривиальная
2) Применение UDA универсализует (деконкретезирует) область применения продукта
3) Реализация механизма UDA это фактически отказ от контроля достаточности и целостности данных средствами СУБД

Если мы все же говорим об одном и том же, видимо мы зашли в тупик, т.к. уровень абстракции на котором мы говорим избыточнен, надо переходить от беседы на пальцах к беседе на SQL 

Чота перечитал я головной пост и подумал что меня чересчур обуяла фантазия на тему EAV. В моей фантазии, я дошел до метосущностей и метоотношений между ними. Пожалуй, меня малость подзанесло и я описал недостатки не той модели которую представил ТС. Наверное то от скуки. Слезно прошу прощения.

Это сообщение отредактировал(а) Zloxa - 15.7.2009, 15:57