progandТак как пользователей может быть много, типов объектов тоже может быть очень много. Будут возможности выбора объектов определенного типа с различными фильтрами,...
И у меня встал вопрос, какая архитектура БД наиболее выгодна?
А если пользователи один по смыслу тип назову по разному? Например, один напишет тип "Игла", другой "Швейная игла", девушка назовет "иголочка", чувачек назовет "иголка блин". В том чиле с ошибкимИ напишут одно и тоже имя Типа? Тогда будут возможности выбора только части подмножеств объектов одного типа? Или на это случай Вы тоже предусмотрите "фтльтр базара".

Программист-ЛюбительБез ПОТСОЯННОГО присмотра специального программиста - контролера качества данных - еав ОБЯЗАТЕЛЬНО превратится в помойку, если пользователи действительно будут добавлять новые свойства, объекты и значений.
"добавлять новые свойства, объекты " - обыкновенно занятие проектровщика БД. Т.е. у них пользователи могут заменять проектировщика. Почему они тада не могут заменит какого-то там программиста (пусть и специального)?
Так что, скорее всего, это для них это не вопрос.
Другое дело, еав есть еав. Все таки это заплатка, а не какая-то там типовая МД. Тут есть риски и программных ухищрений и излишенго роста энтропии проограмного обеспечения (ну типа эффектов помойки разного рода).

Arhat109ТЫСЯЧА таблиц в ОДНОМ запросе через UNION по 100 строк - далеко не факт, что будут быстрее чем 4 таблицы (EAV) по 100 тысяч строк в ОДНОМ запросе.
Еще может иметь значение, что SQL все же заточен под соотвествие структуры МД структуре предметной области (ПО): в списке SELECT - Колонки, FROM Таблицы - элементы стуктуры. Если в ПО есть информация Зарплата (страховой, месяц, зарплат), в МД, например, таблица Зарплата (страховой, месяц, зарплат). То запросы о зраплате всех, нескольких, за квартал, и т.п. почти на естественном языке. Для EAV даже тут ломняк думать. В более сложных случаях тем более. Учитывая, что и с ОЦ в EAV все сложнее, то в запросах, возможно, надо еще учитвать возможную большую чем в нормальной МД мусорность данных.

ПО сути EAV - это "плохая" РМД. РМД потому что там все равно таблицы, SQL и декларативный способ для реляционных БД. "Плохая", потому что нарушается требование качества структурированных МД о соотвествии структуры МД структуре ПО: 4 таблицы вместо ТЫСЯЧИ.

Вот XML, NoSQL и т.п. - там другой тип МД - не РМД. Как бы они, насколько можно, заточенный под их структурирование.

В случае ТС РМД, может быть, не совсем адекватна. Возможно, "гибридная" РМД и ЕАV все же меньшее зло чем другая МД. Однако, чистая ЕAV, скорее всего, выглядела бы привлекательно, если бы БД создавлись с целью занять персонал их набором, а извлекать информацию совсем бы не требовалось.

Arhat109vadiminfo,

много слов "ни о чем"... EAV != РМД. Это своя МД, моделируемая в РМД небольшим набором таблиц... или большим и динамическим DDL ... или "в сочетании".

, ежели моделировать, то надо делать это "целиком" с ОЦ и т.д. и всё встает на свои места.

Мало слов ни о чем. Свои какие-то предстаывления о МД.
По типу EAV - РМД (из таблиц, SQLи деклаоатиыные ОЦ типа ключ, внешний ключ, ограниченя на значения). На Вашем языке "моделируемая в РМД ".
Конкретная МД всегда "своя". Вы бы читали внимательнее "много слов". Там было про другие типы МД типа XML.
А конкретная МД всегда "своя". Т.е. ЕАВ РМД, только "вывернутая на изнаку" как тут ея када-то спрашивали.
"динамическим DDL" это уже из области компилирования какого-то кода, что можно для любой МД. На "свои места" декларативные ОЦ в РМД встают, если с структурного соотвествия МД ПО в силу того, что их так задумал автор данного типа МД.