забыл никДолго думал в каком топике запостить, но все же выбрал этот.

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

Покопавшись в интернетах, пока отсеяли NoSQL и OODB, фиксированная структура тоже не подходит. На данный момент склоняемся к использованию EAV(Entity-Attribute-Value) модели. По факту три главных таблицы Entity-Atribute-Value и несколько для BooleanAttr, TextAttr ... и тд. Основные проблемы - при каждом запросе куча джойнов, сложно разобраться в схеме, нельзя сделать поле реквайред или задать диапазон значений. Планируем победить это так - Создать материализованные виды над каждой энтити, а для констрейнтов свою таблицу, и навернуть перситсенс слой сверху, который будет разбираться что и куда.

Решение громоздкое и сложное, но достойных альтернатив не вижу, может у кого есть подобный опыт или хорошие идеи? Рассмотрим любой вариант.
Вопрос от дилетанта. Чем это отличается от того же yandex market'а, где товары имеют кучу произвольных параметров/атрибутов (document oriented db)?