Всем доброго дня!
СУБД: реляционная - MsSql
Есть различные категории товаров.
Каждая категория товара имеет свой набор хар-тик для товаров.
Харк-тики могут различного типа: число, текст, значение списка, множественное значение списка

Поэтому напрашивается вот такая вот таблица хранения значени при первом рассмотрении:
___________________
ProductPropertyValue:

ID
ProductId (ид товара)
PropertyId (ид свойства)
ValueDecimal (хранение значения типа Decimal)
ValueText (хранение значения типа Text)
ValueListId (хранение ид списка предустановленных значений при связи много к одному, т.е. один товар может иметь одно значение хар-тики - Цвет: красный)
__________________________

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

Вариант, который у меня напрашивается следующий: не делать уникальным значение ключа ProductId PropertyId и дать возможность добавлять несколько значений с одинаковыми значениями этой связки.

Вопросы.
1) Какие есть альтернативы моему варианту?
2) Где слабое место описанной реализации?
Спасибо!

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

У них полей хар-тик там было чуть более 500 суммарно (представляете себе масштаб таблицы).

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

Кот МатроскинВам эта причина кажется убедительной? :)

Увы, да! Надо стараться подстраховываться.
Хотя, предвижу, что Вы можете сказать в ответ: "от корявых рук не подстрахуешься".

Про выходы согласен - он не один.
Кстати, как альтернатива EAV и длинной таблицы хар-тик - это, действительно, набор таблиц под каждый раздел хар-тик.
Это очень оправдано в том плане, что размер одежды, только в одежде, и такой хар-тики нет в электронике.

LSVLexNext Выход тут один: делать таблицу хар-тик 1 к 1 к товару.
Т.е. название и описание, цены мы храним в одном месте, а вот если нужны хар-тики, то при необходимости подключаем связанную таблицу .Берем банальный интернет магазин. Допустим там 300000 товаров (неск. сотен групп) и большинство имеет какие-то поисковые х-ки.
Сколько понадобится полей в этой связанной таблице ?
Что делать если постоянно появляются новые х-ки товаров (ежедневно) ?
Добавлять поля ? На лету ?
Неправильно вставили. Удалять поле ?

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