Возвращаясь к теме. При принятии архитектурного решения приходится взвешивать очень много за и против. Однозначного ответа хороша ли идея OLTP - ООБД, OLAP - РСУБД нет. Она может быть хороша в одних условиях и совершенно неприемлема в других. За промышленными РСУБД - многолетний опыт использования, устоявшаяся терминология, матаппарат, стандарты, широкий рынок специалистов, саппорт, известные приемы масштабирования, возможность применения акселератора на основе уже упомянутых column-oriented databases, псевдо-ООБД-настройки, интеграционные платформы, аналитические системы, перечислять можно долго... все эти факторы настолько снижают риски внедрения системы OLTP-OLAP на основе РСУБД от одного известного вендора, что применение дополнительной технологии становится неоправданным.
С другой стороны, можно представить себе быстро растущий-изменяющийся бизнес, где фокус смещен на развитие OLTP, оперативной отчетности мало или вообще нет, быстрого роста объема данных не предвидится или хочется выиграть в деньгах здесь и сейчас, приняв и поняв все риски. В общем, рассматривать этот вопрос в отрыве от реальности, ИМХО, бессмысленно.

Fuzzy Титов АлександрВозвращаясь к теме. При принятии архитектурного решения приходится взвешивать очень много за и против. Однозначного ответа хороша ли идея OLTP - ООБД, OLAP - РСУБД нет. Она может быть хороша в одних условиях и совершенно неприемлема в других. За промышленными РСУБД - многолетний опыт использования, устоявшаяся терминология, матаппарат, стандарты, широкий рынок специалистов, саппорт, известные приемы масштабирования, возможность применения акселератора на основе уже упомянутых column-oriented databases, псевдо-ООБД-настройки, интеграционные платформы, аналитические системы, перечислять можно долго... все эти факторы настолько снижают риски внедрения системы OLTP-OLAP на основе РСУБД от одного известного вендора, что применение дополнительной технологии становится неоправданным.
С другой стороны, можно представить себе быстро растущий-изменяющийся бизнес, где фокус смещен на развитие OLTP, оперативной отчетности мало или вообще нет, быстрого роста объема данных не предвидится или хочется выиграть в деньгах здесь и сейчас, приняв и поняв все риски. В общем, рассматривать этот вопрос в отрыве от реальности, ИМХО, бессмысленно.
Сказал -- как отрезал :)) Ни добавить, ни прибавить, поспорить не с чем.

:)

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

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

А как решается такая задачка :
есть 2 похожих объекта, имеющих много общего, но отличных в деталях, хранить их в архиве надо в одной таблице. А теперь добавим третий туда же, или поменяем один из 2-х. В случае РСУБД для OLTP все решится внутри OLTP, не затронув ничего снаружи.

Теперь представим, что наша OLTP использует справочники, которые обычно ведутся отдельно в другой системе на реляционке. Как мы будем заливать эти справочники в ООБД? А их надо регулярно обновлять, желательно по факту изменения...