[quot Максим Н]Раскажу, что мне надо.
Необходимо оперативно сохранять и производить операции с объектами, создаваемыми пользователем в рантайме.
Например я создал класс "Дом" (автомобиль, завод и т.д.) и создал несколько объектов, затем мне требуется посчитать например общую площадь домов или количество поребляемой электроэнергии, или еще чего (все что в атрибутах есть).
Вопрос 1. Вы - это пользователь приложения? Правильно?
Вопрос 2. Терминология:

Класс
Атрибут класса
Объект

Правильно?

В предыдущей теме, которая, как оказалось, Вас совсем не интересует, мы использовали терминологию

Тип сущности
Свойство типа сущности
Сущность

Вы хотите использовать терминологию ООП, но ООП, как и любой другой метод программирования никакого отношения к БД не имеет.

Вопрос 3. Уточню: пользователь приложения создает класс, создает атрибуты класса, определяет связи между классами, после чего создает объекты классов, связывая их с использованием описания связей между классами.
Правильно?
Или к примеру есть графический редактор, который позволяет создавать пользователю свои примитивы (многоугольник, параллелепипед, восьмигранник, семигранник и т.д.), а потом использовать их с другими объектами. Причем, чтобы можно было посчитать общую площадь размещенных фигур, длину линий и т.д.

Что для этого подойдет? Мне приходит в голову только EAV, но есть опыт работы с этой моделью, так что это последний вариант.
Максим НЧто скажите о ООБД?
Вероятно, Вы имеете в виду объектно-ориентированные или объектно-реляционные системы обработки и хранения данных (иногда их не корректно называют ООСУБД и ОРСУБД)?
Максим НСможет ли под эти цели подойти документоориентированные БД?
Разумеется. Ведь раз вы используете такую терминологию (БД), то Вы говорите о том, где хранить данные. Конечно, их можно хранить и в "документоориентированных БД".

Максим НРаскажу, что мне надо.
Необходимо оперативно сохранять и производить операции с объектами, создаваемыми пользователем в рантайме.
Например я создал класс "Дом" (автомобиль, завод и т.д.) и создал несколько объектов, затем мне требуется посчитать например общую площадь домов или количество поребляемой электроэнергии, или еще чего (все что в атрибутах есть).
Или к примеру есть графический редактор, который позволяет создавать пользователю свои примитивы (многоугольник, параллелепипед, восьмигранник, семигранник и т.д.), а потом использовать их с другими объектами. Причем, чтобы можно было посчитать общую площадь размещенных фигур, длину линий и т.д.
Что для этого подойдет? Мне приходит в голову только EAV, но есть опыт работы с этой моделью, так что это последний вариант.
Что скажите о ООБД?
Сможет ли под эти цели подойти документоориентированные БД?
Вот цитата из Вашей предыдущей темы:

"Я несколько раз поднимал вопрос о включении EAV в список моделей верхнего уровня. И я удовлетворен тем, что это предложение не рассматривалось никем. Поясню лично Вам - почему. EAV, как и РМД, не обладает необходимыми семантическими свойствами, чтобы справиться либо с ролью модели верхнего уровня в архитектуре "модель+маппинг+модель", либо с ролью единственной модели в архитектуре "модель". Таким образом, эти две модели могут "конкурировать" лишь как модели нижнего уровня. Однако, я ни в коем случае не говорю, что EAV - вместо РМД, как Вам хотелось бы. Так говорят в некоторых случаях из-за известных ограничениях "реляционных систем", которые мы обсуждали в других специальных темах, в частности, в темах о вынужденной необходимости использовать EAV."

В ней я поясняю, что EAV относится к МД нижнего уровня, и предназначена для хранения данных. Она применяется из-за хорошо известных недостатков другой модели нижнего уровня - РМД. Сейчас, насколько я понимаю, Вы говорите не о хранении?
Но, с другой стороны, применяя формулировки "ООБД", "документоориентированная БД", Вы вроде бы говорите о хранении данных?:)
Если Вы говорите о хранении, то можно сравнивать: РБД, EAV-БД, ООБД, документоориентированную БД.
Если Вы говорите не о хранении, то упоминать EAV вообще никакого смысла не имеет.
Но тогда и это мое уточнение не относится к теме хранения данных:

Уточню: пользователь приложения создает класс, создает атрибуты класса, определяет связи между классами, после чего создает объекты классов, связывая их с использованием описания связей между классами.
Правильно?

U-geneЧестно говоря, тутошних, в соседней ветке, страданий (и многих других) уже не воспринимаю.
Как показывает следующее предложение - это просто литературный оборот, чтобы как-то по-эффектнее объяснить отсутствие возможности (например, времени нет) что-то сказать по существу.
U-geneПо мне, они вызваны отсутствием подходящего инструмента, включающего подходящий язык.
Разумеется. Вы правильно поняли причину появления и той и этой темы.
U-gene"Подходящий" в данном случае значит, что он обладает средствами для выражения любой из обсуждаемых там "М"
В той теме аспект манипулирования пока не рассматривается (и, соответственно, маппинг, на этом уровне). Вполне очевидно, что такого языка нет.
U-gene("моделями данных" я их назвать не берусь, за схемы данных они, конечно, сойдут)
Просто умышленная неправда, на мой взгляд. То, что аспект манипулирования на уровне МД верхнего уровня пока не рассматривается, не делает МД "схемой". Между этими понятиями нет вообще ничего общего.
U-gene - точно так же как реляционные системы обладают средствами для выражения "M0".
Разумеется, ведь в М0 то, что называется "связью", является сущностью:) М0 изначально была ориентирована на РМД. Уточню Вашу мысль "точно так же как реляционные системы обладают средствами для выражения M0, М3, М4, М5". Более того, хотя маппинг и нелегок при использовании М1 и М2, он возможен, кончено же, и он двухсторонний разумеется (иначе архитектура просто не реализуема). Следовательно, и их в Вашу фразу можно вставить. И о чем Вы хотите сказать? LSV это уже ясно сказал: модели верхнего уровня не нужны, РМД самодостаточна. И темы эти не актуальны, ни та, ни эта. Но эта мысль итак уже хорошо известна:)

U-geneЧАЛ, я Вас неконструктивно попрошу не интертрепировать мои слова. Ваша логика ущербна даже в том, что в ответ на мое предложения "я не берусь", Вы заявляете, что это ложь - то есть, судя по Вашему, я таки берусь, но тщательно отмазываюсь?
В общем,"не читалпонял, но осуждаю".
Я ничего не интерпретирую. Так как читаю полностью то, что Вы написали. А не одно только словосочетание "я не берусь". Это МД, а не схемы. Ничего общего нет между МД в первом смысле и "схемами". Я абсолютно уверен, что Вы это знаете. Если бы не был уверен, не стал бы употреблять слово "неправда":)

Максим НБредятинаВопрос 1. Вы - это пользователь приложения? Правильно?
...
Вопрос 3. Уточню: пользователь приложения создает класс, создает атрибуты класса, определяет связи между классами, после чего создает объекты классов, связывая их с использованием описания связей между классами.
Правильно?

Да, все верно.
В предыдущей своей теме к сожалению потерял нить через несколько страниц. Попробую прочесть заново.
В той теме рассматривается архитектура "модель верхнего уровня + маппинг + РМД". А в этой:
Максим НБредятинаРазумеется. Ведь раз вы используете такую терминологию (БД), то Вы говорите о том, где хранить данные. Конечно, их можно хранить и в "документоориентированных БД".

Вот как раз сейчас на них я и остановил свой выбор.
рассматривается, значит, архитектура "модель верхнего уровня + маппинг + документоориентированная МД". Ну что же, тоже интересный вопрос, раз архитектура "модель данных" не годится по политическим или экономическим причинам. Авторы М3, М4 и М5, вероятно, выскажутся по поводу маппинга на эту МД нижнего уровня. Впрочем, ViPRos уже высказывался в том духе, что лучше всего использовать РМД на нижнем уровне. Вы, как я понимаю, так не считаете.

Максим НБредятина Ну что же, тоже интересный вопрос, раз архитектура "модель данных" не годится по политическим или экономическим причинам.
Уважаемый Бредятина, объясните пожалуйста как можно практически использовать РМД для описанной задачи (не считая EAV конечно) или киньте ссылкой. Спасибо.
Где я сказал, что для описанной задачи "можно практически использовать РМД"???
Про EAV крайне не корректно. Так как EAV - это уровень хранения. Ее можно использовать вместо РМД. Если Вы говорите об архитектуре "модель данных" (без маппинга между моделями), то такой вопрос лишь частично затрагивается в Вашей первой теме (см. критерий К2). В этой теме Вы рассматриваете архитектуру "модель верхнего уровня + маппинг + не РМД", а именно, "документоориентированная МД".