Bogdanov Andrey FuzzyА кто говорил про преимущества ООБД перед РБД в поиске ???
Я лишь утверждал, что потерь при этом нет. Примерный паритет.
Выигрыш будет, когда найденные документы начнём из базы доставать, юзеру показывать, менять и обратно в базу сохранять. Т.е. выполнять непосредственно саму работу с базой, для чего OLTP-система и предназначена. Тут-то Вы со мной согласны?Вы вовсю хотите чтобы я с вами спорить начал. А я всего лишь понять хочу.
В данном случае я вижу, что если мы просто храним объекты, как есть, то непонятно как организовать приемлимый по скорости работы поиск. В качестве решения вы предложили хранить объекты в таблицах, но если мы храним объекты в таблицах, то занчит, что ООБД при чтении/сохранении занимается преобразованием данных (пусть это скрыто от программиста) из объектного представления в реляционное и обратно. Но тогда я не понимаю как мы можем получить выигрыш в производительности на этих операциях, если сейчас все системы построенные на РБД делают ровно то же самое.
Проясню свою мысль: объекты мы безусловно храним как есть. В таблице я предложил хранить только индекс , причём скрыто от программиста и от объектной модели приложения, чиста где-то внутри ООБД. Так понятнее?
И ещё: я же не разработчик ООБД. Может, там другой какой подход к индексам используется... Вы можете похвастаться, что полностью понимаете, как строятся индексы тем же ораклом каким-нибудь? Многим программистам непонимание таких деталей не мешает успешно трудиться. Просто все знают -- хочешь ускорить поиск, используй соответствующий индекс.

Bogdanov Andrey FuzzyПроясню свою мысль: объекты мы безусловно храним как есть. В таблице я предложил хранить только индекс , причём скрыто от программиста и от объектной модели приложения, чиста где-то внутри ООБД. Так понятнее?Понятно, но за счет чего получается выигрыш в производительности? Если ООБД делает те же операции при сохранении (пусть скрыто от программиста), что и написанный руками маппинг Java-классов в РБД? С выигрышем в скорости разработки я согласен (правда по моему опыту использование средств быстрого написания приводит к тяжелому сопровождению :) ), но обоснования для выигрыша в скорости сохранения пока не вижу.
Не делает ООБД те же операции, что и маппинг. Объект сохраняется как есть , а не раскладывается по десятку таблиц. За счёт этого и выигрыш в скорости.
Основной же выигрыш, как мне кажется, не при сохранении объекта в базу (тут в конце концов ничего особо сложного нет, замапить объект в РБД), а при извлечении объекта из базы . Тут-то понятно, почему?

Bogdanov Andrey Fuzzy Объект сохраняется как есть , а не раскладывается по десятку таблиц. За счёт этого и выигрыш в скорости.
Тогда объясните мне, что значит "сохраняется как есть"? Прямо байт за байтом из памяти переписывается? Всякие указатели в любом случае должны "перекодироваться", индексы нужно расчитать и т.п.

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

Bogdanov Andrey FuzzyА вот если мы всё-таки хотим использовать ООП и все его преимущества? Как в этом случае РБД сможет минимизировать дисковые операции, которых будет на порядок или два больше, чем в ООБД?И зачем вы мне эти цифры взятые с потолка суете? Возможно, что в для ваших реализаций систем с использованием РБД эти цифры и имеют отношение к реальности, но это скорее говорит о вашем неумении использовать РБД, чем о преимуществах ООБД.
Расскажите, ради каких преимуществ ООП вы делаете такое количество ненужных дисковых операци? Приведите реальные примеры, в которых РБД делает на два порядка чтений больше.
Я еще раз повторю реальный пример, который нужен во всех OLTP системах и который пока в ООБД выглядит менее привлекательно - показать пользователю "грид" с некоторым списком. РБД позволит прочитать с диска и передать по сети ровно те данные, которые будут показаны пользователю (в реальности читается несколько больше, но максимум в два раза). Для ООБД я не знаю достаточно оптимального решения.
А я тогда ещё раз повторю свой вопрос: вы НЕ используете ООП в своих приложениях и НЕ строите и НЕ используете объектную модель? В ваших приложениях нет и не было классов вроде Договор, Документ, Счёт, Накладная, Товар и т.п.?

vadiminfo FuzzyА я тогда ещё раз повторю свой вопрос: вы НЕ используете ООП в своих приложениях и НЕ строите и НЕ используете объектную модель? В ваших приложениях нет и не было классов вроде Договор, Документ, Счёт, Накладная, Товар и т.п.?
ООП не обязательно классы "вроде Договор, Документ, Счёт, Накладная, Товар и т.п.". Это могут быть классы вроде Датагрид, Рекордсет и т.д. Причем в плане одного из основных преимуществ ООП - повторного использования, скорей всего, значительно превосходят классы Объектной модели.
Зато значительно уступают по скорости разработки, наглядности, надёжности, и лёгкости внесения изменений и дополнений. Абстракция уровнем ниже. Не так ли?
Ну да ладно, мы отклонились от темы. Ещё раз -- если не строить объектную модель, то ООБД вообще просто-напросто не нужна.
А вот если объектную модель строить, то ООБД даст РБД сто очков форы и всё равно выиграет.

vadiminfo FuzzyЗато значительно уступают по скорости разработки, наглядности, надёжности, и лёгкости внесения изменений и дополнений. Абстракция уровнем ниже. Не так ли?
Ну да ладно, мы отклонились от темы. Ещё раз -- если не строить объектную модель, то ООБД вообще просто-напросто не нужна.
А вот если объектную модель строить, то ООБД даст РБД сто очков форы и всё равно выиграет.
Все от того, что Вы выбираете отдельные достоинства и недостатки.
Вы сказали про ООП. Я привел Вам, пример, что главное достоинство ООП с другими классами.
И абстракиция там возможно выше: она в БД выше, чем в приложении ориентированном на конкретных юзеров.
А с чего Вы взяли, я извиняюсь, что повторное использование кода-- это главное преимущество ООП? К тому же, Вы, видимо, имели в виду повторное использование в разных приложениях?
vadiminfoВы тогда начали говорить о других достоинствах ООБД. Причем, тоже все не очевидно.
Потому, что мне лично эти преимущества кажутся более важными.
vadiminfo
И последний Ваш вывод, потому тоже далеко не очевиден. Судите сами, если бы так было, то с начала 90-х ООБД давно бы вытеснила РБД. Потому, что они не просто так "строят" на удачу, а сначала выбирают принцип построения.
С моей т.з., ООБД не вытеснила РБД потому, что в ООБД очень сложно выполнять заранее не предусмотренные запросы.
vadiminfo
Единственное на что Вы расчитывали, это сохранить объекты приложения в БД, и тогда типо не надо проектировать БД. В это могут верить проггеры знающие ООП, но пришедшие в область БД из других проблемных областей. Но все дело в том, что технолгоии БД имеют такое значние в ИТ, и по сути дали наиболее значительный прирост в производительности ИС, не за счет того, что научились сохранять перманенто данные прог. Есть кое-что и другое. И это другое предполагает, что БД в общем случае проектируется еще до приложений. И имеет значение именно МД в БД, а не внешние МД приложений при сравнении БД. Потому Ваше преимущество, может впечатлять, скорее всего, ООП прогерров недавно пришедших в БД из других областей. Есть, скорей всего, значительно более важные для господства той или иной МД в ИТ.
Ну, это известно, что на ООПшников из других областей часто и составляют большинство двигателей ООБД. Но этого вряд ли достаточно. Сами производители ООСУБД в основном не них, скорей всего расчитывали.
Уважаемый vadiminfo, Вы так утверждаете, будто на сегодняшний день не существует решений, где программер полностью практически изолирован от МД в БД, а работает лишь с объектной моделью. Довожу до Вашего сведения, что это не утопия. Такие фреймворки мало того, что существуют, но некоторые из них являются де-факто стандартом корпоративной разработки (в частности, в России).
И вот когда мы хотим работать с объектной моделью и РБД, мы и сталкиваемся с object-relation impedance mismatch. А ООБД позволяет этого избежать.

Bogdanov AndreyПроснулся в Новом году и почему-то на sql.ru потянуло. :)
Всех с праздником.
FuzzyА я тогда ещё раз повторю свой вопрос: вы НЕ используете ООП в своих приложениях и НЕ строите и НЕ используете объектную модель? В ваших приложениях нет и не было классов вроде Договор, Документ, Счёт, Накладная, Товар и т.п.?Отвечаю на ваш вопрос: В моих приложениях были указанные классы. Более того, они описывались не только как java-классы, но и как классы в "машине операций" - надстройке, позволяющей модифицировать поведение бизнес объектов без "программирования".
Но это не значит, что мне всегда и везде требовались полностью инстанцированные экземпляры класса. В подавляющем числе случаев от класса требуется один-два атрибута. Соответственно в большинстве случаев при создании экземпляра и грузятся из базы только данные одной "заголовочной записи". Остальные атрибуты подгружаются по мере необходимости, при обращении к ним. И именно РБД балгодаря тому, что объект хранится "кусочками" позволяет здесь добиться выигрыша. И, кстати, я с ходу не припомню случаев, в которых мне бы требовался сразу весь бизнес-объект целиком.
Ещё разок -- ООБД (по крайней мере db4o) прекрасно позволяет гибко управлять загрузкой иерархии объектов. Можно инстанциировать объект, но не загружать все его мемберы, а загружать их по мере навигации по объектным ссылкам.
И как раз именно благодаря тому, что объект в РБД хранится "кусочками", размазанными по разным таблицам, она и проигрывает ООБД.
Например.
Допустим, нам нужно реализовать просмотр накладных из прошлого примера, класс Invoice. В ООБД мы сделаем так: выбираем из базы интересующие нас (по условиям отбора) объекты соответствующего класса, глубину иерархии указываем 0. База вернёт нам коллекцию объектов, у каждого из которых вместо члена lines стоит null. Примерно то же самое будет и для РБД, только объекты нужно будет самому собирать, верно?
Затем юзер выбрал какую-то накладную, хочет её поглядеть. Что делает РБД, чтобы полностью загрузить объект -- выполняет селект(-ы), да ещё и с объединением (-ями) таблиц, или другими словами, шарится по всей базе в поисках нужной информации. И потом из полученных данных опять-таки руками нужно строить объекты и связывать их друг с другом. Не правда ли?
А что делает ООБД, когда мы просим её полностью инстанциировать нужный объект -- используя объектные ссылки, которые непосредственно указывают на месторасположение объектов, сразу и без всякого поиска загружает нужные объекты. И руками при этом делать ничего не нужно, а следовательно, нет возможности ошибиться (особенно при внесении изменений).
Согласны, что по времени ООБД однозначно разорвёт РБД?
Bogdanov Andrey
Ну и все вышесказанное не отменяет использования упомянутых vadiminfo классов визуализации. Есть класс "датагрид", который умеет работать с коллекцией объектов. И т.п.

FuzzyЗато значительно уступают по скорости разработки, наглядности, надёжности, и лёгкости внесения изменений и дополнений.По поводу скорости разработки соглашусь, ну а все остальное (наглядность, надежность, легкость изменений) достаточно спорно.
Кажется, у Вас небольшой опыт разработки в ОО-стиле. Другим ничем такое мнение не могу себе объяснить. Вся ОО парадигма имеет своей целью наглядность, надёжность и лёгкость изменений. Если не это, зачем она вообще нужна, по Вашему мнению?
Bogdanov Andrey
За свою практику у меня сложилось устойчивое мнение, что хорошая модель данных на порядок важнее для последующей жизни системы. Видел много "быстро разработанных приложений", где структура базы данных подчинялась используемой при пограммировании приложения структуре классов. После двух-трех лет существования такой системы разобраться в ней и попытаться что-то доработать было уже весьма затруднительно.
Совершенно с Вами согласен -- если мы подчиняем структуру РБД объектной модели, то через какое-то время разобраться в этой структуре невозможно. То же самое происходит и в обратном случае -- если у нас отличная модель данных в РБД, то от объектной модели у нас остаются рожки да ножки, пародия на ООП.
Отсюда вывод -- или ООБД, или забыть про ООП. Или иметь проблемы, либо с МД в РБД, либо с объектной структурой.

vadiminfo Fuzzy
Потому, что мне лично эти преимущества кажутся более важными.

Не все что кажется есть золото. По крайней мере, подход при выборе на том, что в какой-то момент что-то показалось, не является самым распространенным на данный момент.
Как быть , например, если нам всем разное кажется. Ну можем перекреститься. А что еще остается?
Как что остаётся? Давайте поспорим, обменяемся мнениями, мы же с Вами на форуме. Сообщите, пожалуйста, почему лично Вам наглядность, надёжность и лёгкость внесения изменений в программу не кажется более важным, чем использование разными приложениями одного и того же кода. Вы что, разработчик ОО-библиотек каких-то?
vadiminfo Fuzzy
С моей т.з., ООБД не вытеснила РБД потому, что в ООБД очень сложно выполнять заранее не предусмотренные запросы.

Однако, мы же не можем ссылаться на Вашу точку зрения, до тех пор пока Вы не будет установлена безоговорчная его авторитетность. А пока это только предположение. В литературе по БД приводятся и другие недостатки, как, впрочем, и достоинства.
А приведите, пожалуйста, какие-нибудь другие принципиальные недостатки ООБД, о которых Вы говорите. Я встречал только упоминания о сложности расчёта агрегатов и невозможность объединений, всё остальное было критикой каких-то конкретных особенностей каких-то конкретных реализаций ООБД, но не ООБД в принципе.
vadiminfo
Fuzzy
Уважаемый vadiminfo, Вы так утверждаете, будто на сегодняшний день не существует решений, где программер полностью практически изолирован от МД в БД, а работает лишь с объектной моделью. Довожу до Вашего сведения, что это не утопия. Такие фреймворки мало того, что существуют, но некоторые из них являются де-факто стандартом корпоративной разработки (в частности, в России).
И вот когда мы хотим работать с объектной моделью и РБД, мы и сталкиваемся с object-relation impedance mismatch. А ООБД позволяет этого избежать.
До появления СУБД проггеры тоже были изолированы, от МД в БД так как ее не было. Так что я не мог утверждать, что таких решений не существует. Они были вообще до появления БД. Будьте внимательней.
Будьте Вы внимательней, я утверждал, что такие решения существуют СЕЙЧАС, и корпоративным стандартом являются СЕЙЧАС.
vadiminfo
Я утверждал, что они, скорей всего, не дали желаемой эффективности (мягко говоря).
А я утверждал, что они, скорей всего, дали желаемую эффективность (поэтому и стали стандартом де-факто).
Я имею в виду 1С, если до сих пор неясно.

vadiminfo Fuzzy

Как что остаётся? Давайте поспорим, обменяемся мнениями, мы же с Вами на форуме. Сообщите, пожалуйста, почему лично Вам наглядность, надёжность и лёгкость внесения изменений в программу не кажется более важным, чем использование разными приложениями одного и того же кода. Вы что, разработчик ОО-библиотек каких-то?

Я про "наглядность, надёжность и лёгкость внесения изменений в программу"
и как это соотносится с повторным использованием ничего не говорил. Я говорил, что повторность кода одно из важных достоинств ООП. Что до "наглядность, надёжность и лёгкость внесения изменений в программу" это все нуждается в уточнениях, что за этим скрывается. Например, причем тут надежность вообще? В каком смысле? ООП проги более надежны? Впервые слышу.
Наглядность и легкость - это вообще что-то субъектитвное.

Пожалуйста, смотрите что я пишу. Вы приписываете мне левые мыстли и потом просите их пояснять.

Хм, я вовсе не приписываю Вам левых мыслей. Я просто переформулирую Ваши слова так, как я их понял, для того, чтобы Вы поправили меня и мы пришли бы к взаимному пониманию. В данном случае я понял Вас так, что Вы считаете, что главным предназначением ООП является повторное использование кода, поэтому и попросил Вас объяснить, почему остальные преимущества Вам не кажутся более важными. А то, что повторность кода одно из важных достоинств ООП, я с этим и не спорю вовсе.
В любом случае, мы уклонились от темы топика.
vadiminfo

Fuzzy
А приведите, пожалуйста, какие-нибудь другие принципиальные недостатки ООБД, о которых Вы говорите. Я встречал только упоминания о сложности расчёта агрегатов и невозможность объединений, всё остальное было критикой каких-то конкретных особенностей каких-то конкретных реализаций ООБД, но не ООБД в принципе.

vadiminfo
Вот из книг по БД. Зачем Вы их не читаете перед открытиме топика? Ну как Вам сказать, зачем... Некоторые читаю, жаль, конечно, что не все :) vadiminfo

Это про ООСУБД
Отсутствие универсальной модели данных
Недостаточность опыта эксплуатации
Влияние оптимизации запросов на инкапсуляцию
Влияние блокировки на уровне объекта на производительность
Сложность
Отсутствие поддержки представлений

О, вот это очень интересно, особенно пп. 3 и 4. А из каких именно книг по БД сведения? Вы не могли бы подробнее развернуть эти тезисы, если Вам не трудно? Это-то я и хотел обсудить, начиная данный топик.
vadiminfo

Fuzzy
Будьте Вы внимательней, я утверждал, что такие решения существуют СЕЙЧАС, и корпоративным стандартом являются СЕЙЧАС.

Я был внимателен. И уточнил, что такие решения были и до появления СУБД.

Fuzzy
А я утверждал, что они, скорей всего, дали желаемую эффективность (поэтому и стали стандартом де-факто).
Я имею в виду 1С, если до сих пор неясно.
Стандарт где-то там принятый, не есть подтверждение эффективности. Подтверждение последней подтверждается иначе: распространееность, лидирующее положение в технологиях, там всякие тесты. А стандарты и я могу налабать. Мало ли их.
1С имело в качестве СУБД MS SQL или вообще файлы dbf.
Т.е. там ниче подтверждающего эффективность ООМД вроде не декларировалось.

Я имел в виду, что 1С -- это сейчас стандарт де-факто , т.е. я как раз и сужу об этом по распространённости этой платформы.
Конечно, 1С имеет МД на РБД, всё верно, но тем не менее программист работает не с записями и таблицами, а с объектами, описывающими предметную область. В более-менее удачной объектной модели и кроется, на мой взгляд, успех 1С. Но и здесь object-relational impedance mismatch приводит к ужасной производительности и страшной структуре данных, ничего не пропишешь.

vadiminfo Fuzzy
О, вот это очень интересно, особенно пп. 3 и 4. А из каких именно книг по БД сведения? Вы не могли бы подробнее развернуть эти тезисы, если Вам не трудно? Это-то я и хотел обсудить, начиная данный топик.


Из Томас Конноли "Базы данных"

Переписывать из Коннроли? Рука устанет.
Я привел их в пример. Суть в том, что на выбор могут влиять различные достоинства и недостатки. А не то что нам кажется в данный момент.

Вот их-то, эти достоинства и недостатки, мы здесь с Вами и обсуждаем, не правда ли? Книгу нашёл, качаю. Посмотрим, что там они имеют в виду!

Bogdanov AndreyИзвиняюсь за долгое отсутствие - праздники...
FuzzyИ как раз именно благодаря тому, что объект в РБД хранится "кусочками", размазанными по разным таблицам, она и проигрывает ООБД.Забавно... А я считаю, что именно благодаря этому РМД выигрывает.

FuzzyСогласны, что по времени ООБД однозначно разорвёт РБД?
Пока не согласен. Вы все напираете на трудоемкость "самому собирать". В чем эта трудоемкость заключается? И чем это "самому" собрать отличается от ООБД? Я пока не вижу, что количество чтений диска существенным образом меньше. А значит ни о каком "порвать" речи пока быть не может.
Послушайте, ну это уже смешно. Я же в предыдущем своём посте подробно расписал все операции, которые, по моему мнению, должны делать РБД и ООБД. И дело именно в количестве чтений диска -- РБД "шарится по всей базе в поисках нужной информации", а ООБД "сразу и без всякого поиска загружает нужные объекты". С какими именно моментами в моём описании технологии работы РБД и ООБД Вы не согласны, можно по пунктам и с аргументами?
А иначе становится неинтересно -- я стараюсь подробнейшим образом расписать даже абсолютно очевидные вещи, а Вы просто пишете "я не согласен". Так у нас с Вами диалога не получится.
Bogdanov Andrey
Если хотите доказать свой тезис, то попробуйте посторить реальный тест и операровать цифрами, а не лозунгами.
Если вы не готовы доказывать, то не надо с таким напором спорить. Я понимаю - вы начали использовать db4o и вам это понравилось, но пока кроме эмоций я ничего не вижу.

Не считаю нужным лично самому перепроверять данные тестов, приведённые на сайте db4o (о чём я, кстати, упоминал ), просто потому, не сомневаюсь в них -- по-моему, всё логично. Вот Вам ссылка , если возражаете против этих тестов, пожалуйста, обоснуйте.
Bogdanov Andrey
FuzzyЕщё разок -- ООБД (по крайней мере db4o) прекрасно позволяет гибко управлять загрузкой иерархии объектов. Можно инстанциировать объект, но не загружать все его мемберы, а загружать их по мере навигации по объектным ссылкам.А почему "еще разок"? Вы раньше упоминали о частичной загрузке объектов?
Вот здесь, например. Кажется, Вы невнимательно читаете.
Bogdanov Andrey
Вот расскажите, как будут лежать на диске накладные со строками? Если внутри каждой накладной лежат ее строки, то каким образом будет производиться загрузка только "хэдеров" без считывания с диска всех данных? Если же строки лежат отдельно, то чем это отличается от РМД?

Отличается тем, что в РБД связь между строчкой и хэдером организуется как ID хэдера, сохранённая в строчке, а в ООБД наоборот -- ID строчек сохраняются в хэдере. Когда загружаем только хэдер, то сами строчки с диска не читаем, а читаем только их ID. Так понятно?
Bogdanov Andrey
Fuzzy
Кажется, у Вас небольшой опыт разработки в ОО-стиле. Другим ничем такое мнение не могу себе объяснить. Вся ОО парадигма имеет своей целью наглядность, надёжность и лёгкость изменений. Если не это, зачем она вообще нужна, по Вашему мнению?
Так мы модель данных обсуждаем или опыт собеседников? Давайте для того чтобы опытом меряться отдельный топик откроем и будем там резюме выкладывать.
ООП имеет некоторые преимущества перед процедурным программированием для крупных проектов. Но какое это имеет значение при сравнении моделей данных - я не знаю. Реляционная модель с равным успехом позволяет вам использовать преимущества ООП (или других парадигм) при программировании приложения.

FuzzyОтсюда вывод -- или ООБД, или забыть про ООП. Или иметь проблемы, либо с МД в РБД, либо с объектной структурой.Хм. А может быть вы просто не умеете их готовить? У меня прекрасно сочетались ООП в приложении с реляционной моделью данных.
Согласен с Вами, что это отдельная тема, но не могу не заметить, что Вы, наверное, единственный человек, который всерьёз утверждает, что никаких проблем с сочетанием ООП и реляционной модели не существует. Для всех остальных неоднократно упоминавшийся в этом топике object-relational impedance mismatch является сильнейшей головной болью и острейшим геморроем одновременно.

Bogdanov AndreyЯ не говорил, что проблем нет. Более того я даже писал, что интересовался подобными решениями. Но это определенно не было самым большим геморроем. Я согласен с тем, что db4o предлагает хорошее решение, которое упростит разработку, но в отличии от вас я пока не вижу в этом решении "серебрянной пули". Более того, по моим ощущениям упрощение разработки получается за счет некоторого поигрыша в производительности (что вполне закономерно) - правда видимо значительно меньшего, чем при использовании hibernate. Когда у меня появится возможность я обязательно попробую этот продукт в деле.
В общем и целом, согласен с Вашими выводами, разве что обобщу их не только на hibernate, а на любой ORM, даже и самописный.
Я сам сейчас как раз пробую db4o в деле -- в общем, конечно, очень приятно, хотя и не без своих нюансов и подводных камней...
Однако, чтобы строить информационную систему на db4o или другой ООБД, необходимо всё-таки решить вопрос с отчётностью. Ведь отчёты на ООБД лабать -- это ужасный ужас. Как Вы считаете, решит ли эту проблему сервер отчётов с OLAP на РБД? Может, другое видите решение?