DDeath Нет, доводов я не увидел , только слова. Где ссылки на пруфы или хотя бы просто объяснить примерно почему?Ссылок не будет, новых доводов тоже. Просто попробую подъитожить
EAV очень плохо в продакшене ибо
1 Это медленно - строка собирается из частей размазанных по таблице. Чем больше полей тем дольше собирается. Поиск по нескольким полям превращается в тихий ужас. Создание параллельной структуры вне субд неизбежно поднимает вопрос о согласованности и транзакционной целостности.
2 Запросы громоздкие, стало быть ошибится легко
3 Все проверки базы данных похоронены в принципе, опечатка в названии сущности или атрибута может быть незамеченной довольно долго
4 Это нифига не более гибко, ибо создавать новые сущности и атрибуты несложно и в традиционном стиле, а править структуру при EAV СЛОЖНЕЕ, ибо никто ошибку не выдаст.
5 Попытка доступа к базе средствами отличными от вашей программы (например постоителем отчетов) неизбежно приведет к созданию вьюх на ваш EAV моделирующих обычную реляционную базу. Если же эти вьюхи материализовать и индексировать, то выигрыш в производительности должен натолкнуть на мысль - а почему бы сразу так не сделать, зачем тогда он (EAV) нужен.
6 Использование продвинутой и недешевой СУБД Oracle в качестве тупого хранилища данных напоминает стрельбу из пушки по воробьям.

В то же время для разработки макета "proof of concept" указанные недостатки не являются критичными, только надо отдавать себе отчет, что в смете должно быть время на рефакторинг кода. Если у вас нет на это времени, это проблема вашего руководителя проекта. Если же рефакторинга проведено не было, макет пошел в продакшн, не удивляйтесь глюкам, тормозам, "лучам ненависти", ярлыкам "говнокод" и т.п.