Использовать ли EAV модель данных?

Я несколько раз почти уже решался реализовать эту модель в своем приложении, но каждый раз меня что-то останавливало. Буквально вчера наткнулся на замечательную презентацию Билла Карвина (смотреть обязательно): http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back , которая окончательно разубедила меня сталкиваться с этой вещью. Вы не получите ровным счетом никакого выигрыша от использования EAV, а только лишите себя всех возможностей, предоставляемых РСУБД.
В качестве альтернативного варианта можно воспользоваться одним из следующих паттернов:
- Single Table Inheritance;
- Class Table Inheritance;
- Concrete Table Inheritance.
Все они (и несколько других) кратко рассмотрены в презентации. Использовать паттерн EAV возможно только в качестве дополнения к более разумным подходам, если всё-таки нужно предусмотреть динамическое добавление 1-2 полей к существующим сущностям. Но ни в коем случае не 10 и не 50 полей.
P.S. EAV - это выворачивание реляционной модели наизнанку. Как написал (а точнее, процитировал своего знакомого) в своей книге (SQL Antipatterns) всё тот же Билл Карвин: "Если взять кота и разобрать его на части, чтобы посмотреть, как он работает, то мы получим неработающего кота". (один из работающих вариантов кота в данной ситуации - документо-ориентированные СУБД).

Поработал тут немного на проекте с EAV моделью. Впечатление - #$@%^ (словами не передать).

EAV задумывалась как гибкая модель хранения данных, сам заказчик может добавлять аттрибуты, не прибегая к помощи разработчиков. На практике же заказчики не особо горят желанием ковыряться в системе и что-то там добавлять. Все-равно это делает программист. И тут вместо простого alter table add column приходится распутывать цепочку черти-чего. Все инструменты работы с базами данных заточены на отображение плоской структуры, а тут нужно отображать дерево.

Но самое ужасное, заказчики предъявляют требования на логику поведения тех или иных объектов. В системе появляются хранимые функции, триггеры и прочее. Только вместо нормальной логики они содержат зубодробильные конструкции типа where attribute_id = 86024327 and root_entity_id = 87641055

В итоге, стоимость поддержки такой системы для заказчика значительно больше.

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

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

Тут есть небольшое обсуждение указанной темы: http://www.askdev.ru/net-platform/2596/Как-выгрузить-коллекцию-объектов-в-БД/new/#answer5282