_мод iscrafmбедные, бедные update и delete... их выгнали из OLTP приюта. вместе с select впрочем.
Забыли наверное что OLTP на 99% это select

Ребята, вы OLTP с OLAP не путаете?

FuzzyНикаких надстроек! ОО надстройки -- это ещё тормознее и сложнее, чем просто вручную мапить объекты в РСУБД.
Гораздо быстрее во всех смыслах использовать сразу ООБД. В этом и суть топика.

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

авторЯ извиняюсь, а кто же заставляет сохранять в ООБД все объекты подряд???

Про подряд я не говорил. Прелесть ООБД в том, что вы храните объекты "как есть", со всеми связими и потрохами. Этим она вас и привлекла, по всей видимости. Для разработчика - супер : не надо на каждый чих лезть в базу и т.д. и т.п. Но, с другой стороны, это означает, что набор данных в ООБД для репликации очень изменчив. Кошмарный сон интегратора.

авторЧто реляционка заставляет задуматься -- это просто не то слово :)

И во многих случаях это очень неплохо, честное слово :)

авторСудя по описанию репликации между db4o и РСУБД, всё делается элементарно и почти автоматически. Реклама?

попробуйте, потом расскажите :) поверьте мне, наткнетесь на кучу всяческих "но".

автор
про обслугу на ООБД где-то соглашусь, конечно. Ну так что ж, на всё новое всегда сначала не хватает персонала. Главное, что технология ООБД + OLAP на РБД -- перспективна.

Давайте разложим все по полочкам. Благо сегодня время есть...
ООБД позволяет быстро создавать приложения, требующие хранения разнообразных по своей природе объектов. Поэтому в первую очередь они нашли применение у веб-программистов. Очень удобно хранить сессии пользователей (персонализация интерфейса), порталы, и т.д. и т.п. Что из этого следует? Это означает, что фактически каждое изменение в логике приложения отражается на структуре данных. Добавление новых сущностей - это ерунда, это происходит и в системах на РСУБД. Главное - это изменение котракта (интерфейса), по которому ваша система взаимодействует с другими системами. Фактически есть 4 основных способа интеграции приложений :
1. на уровне GUI. Надежность - без комментариев, используется если ничего другого нет.
2. на уровне SDK. Требует разработки вменяемого SDK, поддержки контракта (совместимость снизу вверх и прочие прелести), подробная документация, интегратор должен знать "потроха" приложения.
3. на уровне БД. Наиболее часто используемый. Понятен большинству. Есть стандарт - SQL. Но и здесь обычно строят еще один слой в виде набора view, процедур или стабильной структуры таблиц.
4. на уровне сервисов. SOA, разговоры про слабое связывание и все остальные модные темы.

Для информации : Промышленные ESB поставляются с адапторами, напрямую поддерживающими только 2 последних уровня.

Вы предлагаете перевести уровень интеграции системы из 3-го во 2-й. И это именно так - ООБД меняется теми же темпами, что и логика приложения (иначе зачем она нужна?). И не надо питать иллюзий насчет волшебной репликации, которая все сделает за вас. Не сделает.
Не питаем иллюзий также насчет того, что у вас - единая система учет+аналитическая отчетность. Это не так. Это две РАЗНЫЕ системы, требующие интеграции. И это ПРАВИЛЬНО, что они разные. Поскольку это надежнее. Почему продолжает жить идея Hibernate и сейчас получает развитие в новом детище Майкрософта - LINQ? Потому что это позволяет использовать РСУБД для интеграции и быструю разработку для быстрой реакции на изменение требований пользователя.
Итого : использовать ООБД для создания отдельного приложения можно. Использовать его напрямую для интеграции, без некоторого более стабильного слоя, нельзя. Таким образом, на мой взгляд, область применения ООБД ограничивается приложениями, занимающимися отображением данных и введение этой технологии в приложение, экспортирующее данные, неоправдано.

_мод FuzzyСелекты всё ещё не нужны.
Упорно не хотите вводить накладную. Для ввода надо прочитать:
поставщика
договор
товар
ед. измерения
Добавить контроль остатков, оперативный анализ, справки и получите 99% селектов против 1%инсерт-апдейт-делете. Такой вот он олтп понимаешь

Уважаемый _мод, ну прочитайте, наконец, определение OLTP, и не используйте этот термин применительно к системам другого класса. Fuzzy, кстати, изначально тоже неверно его применил. Правильное название систем, о которых вы говорите - это "модуль ERP" (предположительно - CRM).