DDeath возможность масштабирования это одна из вещей о которой не стоит забыватьEAV убивает масштабирование на корню просто в силу своей архитектуры. Эту мысль вам пытались донести
DDeath Если будут более разумные предложения, с радостью выслушаю. Традиционные классические ER диаграммы. Традиционный классический анализ нагрузки и поиск узких мест.

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

DDeath Если кому интересно, вот диаграммаСкажите, вы правда ничего не поняли или просто издеваетесь?

DDeath Вот ещё один которому колит глаза аббревиатура AWS Гугль мне выдал American Welding Society (AWS) Сваркой соединяете базу
DDeath я выложил диаграммуНечитаемую
DDeath вот ссылка на диаграммуГораздо лучше.

По сабжу - у вас есть задача - есть некая база, к которой ходят некие клиенты за некими данными, и на которую накладываются некие ограничения. Мне, как форумчанину интересно какая именно задача, на каких моментах стоит заострить внимание и как бы я сам решал данную задачу. Вы же спрашиваете об особенностях вашего решения, не напрягаясь обоснованием почему было выбрано так или иначе. Вполне возможно что вы правы, но некоторые слова типа: "любые сущности" "могут иметь разные атрибуты" наводят на мысль что вы не решаете свою задачу, а пытаетесь решить ее в "общем виде". Грабли этого подхода хорошо известны, если вы хотите по ним пробежатся, то смотрите про "сам себе злобный буратино".

DDeath У нас совмещается в проекте большое количество под проектов будь то магазин , бизнес площадка, площадка для поиска работы и т.д и всё это должно быть в одной базе и перевязано между собойТо бишь о задаче, запросах, оптимизации вы не знаете или не хотите узнавать, надеясь что все будет хранится в EAV структуре и само как нибудь устаканится. И при этом печетесь о производительности.
DDeath Проблема возникла тогда , когда нам нужно было создавать атрибуты для сущностей и давать им значения и мы решили взять сделать её по типу EAV (хотя тогда и не знали что это такое), когда возникла задача сортировать по значению атрибута, оракл ругнулся что тип NCLOB не сортируемсм пост от _мод, только уточню, что наверное не varchar2, а nvarchar2 для значений втискивающихся в 4000 символов. Для более длинных значений, пусть клиент идет за добавкой в дополнительную таблицу, например найдя в конце TITLE - "продолжение следует".

авторEAV убивает поиск по базе.Ага, и каждая строчка собирается в разы медленнее, чем в обычной структуре

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

Leonid Kudryavtsev Дублирование информации при нынешних ценах на жесткие диски не выглядит таким уж большим расточительством.Главная беда дублирования информации не цена хранения, а согласованность (девятый вагон это не тот что перед десятым, а тот что после восьмого)
Leonid Kudryavtsev для неподготовленного программиста EAV всем хорошДля молодого программиста EAV хорош именно свободой.
Не надо приглашать ДБА на интимный процесс общения с заказчиком, не надо пытать аналитика, чтобы узнать как именно изменятся правила игры (у нас гибкая структура),
не надо натыкатся на ограничения или устанавливать права доступа (чтобы какая та база меня ограничивала - НИЗАЧТО),
не надо изучать этот странный SQL - ограничимся привычными getValue, setValue
А если будет тормозить, то применим самую новомоднюю технологию ABC (заодно научусь с ней работать) и/или XYZ - (тоже будет хорошо в резюме смотрется.
Я все это знаю точно, потому что сам был таким.
Leonid Kudryavtsev живет, эксплуатируется и продается. А вот в это верю абсолютно. Маркетинг рулит. Но то что система приносит бабки не делает ее прямой.
Leonid KudryavtsevИногда более-менее адекватная модель просто не существует. И попытка сделать сначала адекватную модель приводит к тому, что все на стадии построения адекватной модели и застреваетТакое бывает на мертворожденных проектах, которые никому не нужны.
Leonid Kudryavtsevнеадекватные люди, которые адекватные задачи сделали неадекватными+1. Партия сказала надо, программист ответил есть, бюджет попилен, а до продакшена авось не дойдет.
Leonid KudryavtsevЕсли же следовать современным стандартам для разработки, то простенькая операция "добавить поле" выльется: изменить структуру таблиц, перегенерить entity/view object'ы, добавить контролы на экран, пересобрать проект, передеплоить и т.д. Даже исключая шаг тестирования...не радостно )))Именно. И наличие или отсутствие alter table add field непринципиально.

DDeath 1. Задача была поставлена так, сделать всё с 0 за 2 месяца или продолжить разработку на криво написанной системе которая работает под Битрикс`ом.
2. Нужно было сделать так чтоб потом начальник когда разговаривал с инвестором и сказал бы ему "Не беспокойтесь завтра функционал уже будет" то функционал должен быть готов.
3. Чёткой задачи нету и требования меняются каждый день.

http://www.sql.ru/forum/24207/e-yordan-kak-vyzhit-v-beznadezhnom-proekte

DDeath я бы попросил вас больше не заходить сюда. Ваша просьба отклонена
DDeath вменяемая критика с приведение доводов, буду рад.То есть мои доводы против EAV для вас были невменяемые. Поищите по этому форуму по слову EAV более другие.
DDeath но обратились мы сюда т.к технологии технологиями а архитектура очень важная штука и мнения важно было услышать.Услышали, легче стало?
DDeath решать проблемы когда нужно то все как бы не причемРешать проблемы все равно придется вам. Хотите вы этого или нет.

По вашему описанию проект выглядит безнадежным. Это не ваша вина, это ваша беда, но вы не одиноки. Советую таки найти и прочитать Йордана.