авторА если это только одна из множества задач, то просто пишите запрос на OQL:
select attr1, attr2 from Objects where [условие]
И получаете результат без необходимости тащить все объекты целиком.
Тогда это не стыкуется с этим:
авторУтверждаю, что систему высокой сложности, для которой разумным является использование объектно-ориентированного подхода ( т.е. задача разбивается на относительно самостоятельные сущности - бизнес-объекты, используется UML-моделирование и разработка клиентских приложений на базе ОО языков программирования Java, C++, C#),
Потому как либо вы на клиента тащите весь объект - потому что клиенти заточен на объекты, либо смысл в таком клиенте пропадает - и собственно смысл ООСУБД становится совсем не понятен.

Мне он и так то непонятен - куда бы приткнуть :)

-- Tygra's --

Таааааакк.... Давайте определимся.
Тема топика:
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
Теперь вроде как получается:
авторРечь идет о специальных каких-то приложениях
Отсюда вывод: нужно побыстрее определиться, о чем же речь, о специальных приложениях, или обо всех ?
Если специальных - то смысла в обсуждении нет, т.к. можно найти такие специальные приложения, где любая СУБД будет медленнее какого-то своего решения.
Если обо всех - тогда реальный пример: было сделано на РСУБД, было плохо, сделали на ООП - пришло щастте :)

======
Есче.
Давайте будем вести речь именно об ООСУБД, а не надстройке над клиентом, которая делает вид, что она работает с ООСУБД, а на самом деле данные лежат в обычной РСУБД. Это непорядок - ОО так ОО. В чистом виде.
Потому далее я веду речь о любой системе - хоть бухгалтерской, хоть складской.

авторЗачем притыкать. Надо просто понять какие преимущества дает ООСУБД.
Вот, пытаюсь....
авторВедь никто, я полагаю, не спорит с тем, что применение объектного подхода к разработке приложения оправдано. Не думаю, что найдется много разработчиков, не использующих на сегодняшний день объектные языки программирования.
Это точно, программировать используя ООП гораздо проще.
авторОбъектные базы просто позволяют программисту сосредоточиться на объектах, а не на структуре таблиц. Нет нужды думать о том, как хранить данные.
А кто такие, эти объекты? Чем они лучше тех же таблиц? Чем лучше сосредоточиться на структуре объектов , чем на структуре таблиц ? И как часто вы лично думаете над тем, как хранить данные? Я вот редко. Они сами хранятся :).
Чем объект лучше таблицы? Чем лучше работа с объектом, чем с таблицей?
авторЯ уверен, что это позволяет серьезно повысить качество алгоритмов и реализацию бизнес-логики при тех же затратах времени на разработку.
Какие ваши доказательства? ((с) шварцнегер)
авторДругой вопрос, что иногда это снижает производительность. Но это является, на мой взгляд, следствием реляционного мышления программиста.
Как мышление может повлиять на производительность системы, в которой менять руками почти ничего нельзя?
авторЯ не претендую на роль гуру. Но то, что я знаю об объектных базах, позволяет мне быть уверенным в том, что пишу. :)
А я вот не знаю. Но чтобы узнать, хочу увидеть хоть какие-то преимущества. Пока не вижу.

авторМне кажется, что нет смысла сравнивать реляционные и объектные СУБД. Это просто способ хранения данных.
Да нет уж, в СУБД часто еще и бизнес-логика находится, так что надо сравнивать, надо.
авторПреимущества - в самом объектном подходе к разработке. А вот это объектный подход к сохранению данных позволяет использовать более эффективно.
И опять: коментарии, доказательства, примеры... Как мне облегчит жизнь объект данных?

====
А вот еще вопрос: хорошо, есть объект данных. Есть у него свойства, как-то с ним можно работать. А где лежит логика работы с этим объектом? Внутренняя логика. В СУБД? Или на клиенте?

-- Tygra's --

О, нашел ответ на свой последний вопрос:
авторВ целом, действительно объектные СУБД всегда имеют тесную интеграцию с самими ОО языками программирования. Т.е. для настоящих объектных СУБД разработки структуры базы данных как таковой не производится - есть некий API и/или расширения языка которые позволяют полностью оттранслировать объектную структуру приложения в структуру базы данных.
К примеру, я просто объявляю Java-класс сохраняемым и все объекты этого класса автоматически получают возможность быть сохраненными в БД (т.е. мне не надо вообще заботиться о том, в какой таблице эти объекты будут храниться и т.п.).
Т.е. получается, что без специального, написанного именно для этой системы и СУБД, клиента, сами данные в СУБД - просто пшик, потому что они из себя ничего не представляют, никаких объектов нет, ничего такого. И смысл sql-запрос делать по ним какой?
Так чтоли? Нуууу, это уже неинтересно :)

-- Tygra's --