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

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

Теперь мне понятно, что Вы имели в виду под ужасом для интегратора -- в случае РБД интегратор будет параллельно менять структуры двух РБД, глядя только в структуру базы, да ещё и пользуясь штатными инструментами производителя РБД, а в случае ООБД интегратор должен будет лезть в код приложения, разбираться в нём и руками править метод для репликации. Так?

Но я так понял, что репликация между ООБД и РБД сделана на движке Hibernate, т.е. нужно будет просто исправить маппинг в конфигурационных файлах, как и в случае с OLTP на РБД (нам ведь по-любому нужно исправить маппинг, если структура объектной модели поменялась, верно?).

vadiminfo Fuzzy...
Возможно, есть и другие главные упреки. Так или иначе сейчас идеи ООБД переживают не самые лучшие времена. Лучшие были в начале 90-х.
всё развивается по спирали... может, уже настало время с новых позиций поглядеть на ООБД?
vadiminfo
Fuzzy
Однако, так ли уж прекрасно и РСУБД справляется с задачами анализа?
Ведь обычно аналитики не используют OLTP-систему для формирования своих отчётов, а используют OLAP-кубы!

Разве обычно? Это только для поддержки принятий решений. В общем к хранилищам данных и ОЛАП для обощенных данных. А для поодержки опретивно прикладных задач полно запросов к детальным данным. Например, средние скользящие с такого-то числа по такое-то уже для ОЛАПа
не лучшее из лучшего. Для него луче периоды. Если в имерениях много значений - тысчи, то ОЛАП может терять свои достоинства.

возможно, я нечётко (:)) выразился, имелось в виду, что OLTP-система и OLAP-система -- это разные базы данных и даже часто физически на разных серверах.
vadiminfo
Fuzzy
Причины этого: а) в случае, если данные находятся в сильно нормализованном виде, запросы по ним выполняются довольно-таки медленно. Особенно, если не построены нужные индексы, а они ведь и не построены в OLTP-системе, т.к. индексы там заточены под задачи бизнес-транзакций, а не анализа; б) какой-нибудь тяжёлый аналитический запрос, этак на пару-тройку часов, может помешать выполнению бизнес-транзакций, что неприемлемо.

Другие в основном причины. В ОЛАП Юзер сам может строить запросы в процессе оперативного анализа.

Какие же? Репортёр для юзера можно и к OLTP-системе прикрутить, как разница?
vadiminfo
Fuzzy
Получается, что OLTP на РСУБД является типичной универсальной системой, которая справляется и с задачами текущей работы с информационной системой, и с задачами анализа. Но обе эти задачи она решает не идеально!

Получается, но идея в том, что в хранилищах данных Данные могут быть не тока от РБД, но и иерахических и доисторичских, потому что для анализа нужны в общем случае и исторические данные.

да ну и пусть, смысл моего вывода -- OLTP и OLAP это разные базы данных, и если для OLAP РБД однозначно (или неоднозначно?) рулят, то OLTP гораздо удобнее строить на ООБД, т.к. для систем этого типа они намного лучше приспособлены, чем РБД.
vadiminfo

Fuzzy

Исходя из этого, не кажется ли вам, что перспективной структурой информационной системы может быть следующая:
а) OLTP-система на ООБД, из отчётов -- только несколько наиболее стандартных. Имеем все преимущества ООБД, перечислять их не буду.

Пока не кажется. По, крайней мере, так как это могло казаться в начале 90-х.
ОЛАП тут не поможет ООСУБД. Она должа сама выдавить РСУБД в оперативных БД. Во всех отношениях.

Обоснуйте, пожалуйста.
vadiminfo
Fuzzy
б) данные из OLTP-системы ежедневно (во время наименьшей нагрузки, ночью) реплицируются в архивную базу на РСУБД. Это позволит иметь ООБД не слишком больших размеров, за счёт архивации неактуальных для текущей деятельности данных.

Не. Совсем не кажется. Все же это разные МД. И одна из них, скорей всего, лишняя. Вместе они могут отрицательно повлиять на качество ЖЗ.

Аргументы?
vadiminfo
Fuzzy
в) по данным РСУБД ежедневно строятся необходимые аналитикам OLAP-кубы, как обычно.

Получится, что каждую из задач мы решим наиболее оптимальным способом. Как вам кажется?
Вот это кажется. Но тока када потребности в оперативном анализе установлены. Вряд ли это надо в любой ИС.
Ну, на любую ИС, конечно, не будем обобщать. Не уверен, что вообще что-то можно сказать о "любой ИС". Давайте обсудим, когда это надо, а когда нет!

_мод FuzzyУ кого получается и почему именно так?
99.9..% OLTP построены на РСУБД, остальное на С и И СУБД
а OLAP как МД придумали специально для задач, тяжелых в РСУБД, хотя есть и ROLAP
такой вот расклад
А когда-то 99.9% всех программ писали на асме, и что? "Дела давно минувших дней, преданья старины глубокой..."

vadiminfo Fuzzyвсё развивается по спирали... может, уже настало время с новых позиций поглядеть на ООБД?

Ну по спирали да. А вот новые позиции каковы? Пока все, вроде, выглядит по старому. А судя по всему, это новое должно быть чем-то очень сильным, чтобы переломить ситуацию. Его бы все сразу заметили.


Fuzzy
возможно, я нечётко (:)) выразился, имелось в виду, что OLTP-система и OLAP-система -- это разные базы данных и даже часто физически на разных серверах.

Это ничего не меняет, тем более, что я писал, что ОЛАП для хранилищ данных - это не тока две разных БД, но это и концепции БД разные. Но в Оракле они в одной БД. Т.е. это ни на что из сказанного не влияет.



vadiminfo
Какие же? Репортёр для юзера можно и к OLTP-системе прикрутить, как разница?

Разница все же есть - это обеспечивается манипулированием данными с кубами. В частности, можно просто Йексель прикрутить. Можно просто кубы спроектировать. И все. Готово. Юзер может крутить по измерения и далать срезы - получая море запросов, которые сложно предвидеть. Включая так называемые шахматки, что важно для нанлиза. Получать тенденции. Т.е. это обеспеичвается самой МД - многемерные представления данных. Это и юзеру проще, чем в репортере.
Без этого ОЛАП вряд ли бы так назывался и имел бы успех. Налабать просто заране выполненые отчеты в мат представлениях - моно и в ОРакле в РСУБД. Они будут по ночам заливаться.



Fuzzy
да ну и пусть, смысл моего вывода -- OLTP и OLAP это разные базы данных, и если для OLAP РБД однозначно (или неоднозначно?) рулят, то OLTP гораздо удобнее строить на ООБД, т.к. для систем этого типа они намного лучше приспособлены, чем РБД.

В общем случае OLAP не база данных, а инструмент. Кубы в хранилище только часть обощенных данных. Там есть и опреративные. Там все.
Вот то, что "OLTP гораздо удобнее строить на ООБД, т.к. для систем этого типа они намного лучше приспособлены, чем РБД." Это то как раз и ключевая проблема. Т.е. именно это и не установлено. На это надеялись в 90-х. Но убедительног подтвекрждения пока это не нашло. Будь оно так РБД бы уже значительно отодвинули. Возможно, где-то и кому-то удобней. Но этого не достаточно. РБД тоже удобна для многих типов приложений, как оказалось.



Fuzzy
Аргументы?

Усложняется разработка, сопровождение (теперь две БД и разные МД, а с ОЛАП и три). Скорость роста энтропии програмного обеспечения возрастает - теперь примочек вдвое больше. Одним из существенных недостатков ООБД - большая сложность разработки. Плохо спроектированная, она более тяжело сопровождается, чем плохо спроетированная РБД.

Fuzzy
Ну, на любую ИС, конечно, не будем обобщать. Не уверен, что вообще что-то можно сказать о "любой ИС". Давайте обсудим, когда это надо, а когда нет!
Это вопро о том, когда надо хранилище данных. Оно в общем случае должно взять и данные от разнх МД. Старых версий. ПОтому и из этих случаев нужно много отбросить. Что же останется?
Взяли РСУБД. Там все есть чтобы лобать кубы в продвинутых РСУБД. На том дело и кончится.
Потому и говорю Вам, нужно ООСУБД вытеснить РСУБД в главном. Но РСУБД налабали ОРСУБД. Что еще больше усложнило ситуацию для ООСУБД, так как сузило типы приложений для ООСУБД где РСУБД не адекватно.
Хорошо, давайте сперва обсудим ключевую проблему -- "OLTP гораздо удобнее строить на ООБД, т.к. для систем этого типа они намного лучше приспособлены, чем РБД". Мне это кажется очевидным, по причинам:
1. Гораздо более быстрая разработка приложения
2. Более удобный рефакторинг
3. Более высокая производительность приложения.
Вы с этим не согласны?

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

Просто изучаю тему совместно с вами. Учусь, задаю вопросы :)
Вот еще что нарыл по теме : раз и
два
интересные ссылки, добавил в свою копилку.
Особенно первая.
А вот вторая собственно о чём? О том, что рефакторинг штука нужная и что с ООБД рефакторинг гораздо проще? Так это и ежу ясно.

Титов Александр Fuzzy
Но я так понял, что репликация между ООБД и РБД сделана на движке Hibernate, т.е. нужно будет просто исправить маппинг в конфигурационных файлах, как и в случае с OLTP на РБД (нам ведь по-любому нужно исправить маппинг, если структура объектной модели поменялась, верно?).

Угу. "Исправить маппинг" - это задача, аналогичная мапингу объектной модели приложения на РСУБД, только делать мы это будем в другом месте, чем раньше - не на слое доступа к БД на с родным высокоуровневом ОО-языке, а в конфигурационных файлах, на PL\SQL и другим, мало подходящими для сложной логики, способом. Т.е. просто смещаем фокус, введя 2 новые технологии (ООБД и Hibernate)
Отвечу Вам цитатой из Вашей ссылки:
[quot http://www.onjava.com/pub/a/onjava/2006/04/12/object-to-relational-database-replciation-with-db40.html?page=2]So what's the motivation to use db4o at all? Why not use a relational database in the first place? There are a number of reasons why you might choose db4o. The fact that the application and database use exactly the same model means that you don't have to write a lot of code to build and execute SQL statements that the compiler can't check and that can be difficult to refactor. You also don't need to write more code to assemble objects from the results. You could use Hibernate directly in the application, which would let you work only with objects in your code. However, the footprint and performance of the resultant application would probably make it unsuitable[quot]

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

2.Рефакторинг? Не знаю. Думаю, что спопровождение при проч равных условиях сложнее и дороже. Т.е. даже неорефакторингенная РБД, может быть проще в соапровождении. И даже менне кавлифицированным персоналом. [/quot]Хорошую ссылку дал Титов Александр в своём посте 5107052, ссылка "два" vadiminfo

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

shelsoftЧто-то все мне это напоминает, "что лучше компилятор или интерпретатор ;o)"

Fuzzyимелось в виду, что OLTP-система и OLAP-система -- это разные базы данных и даже часто физически на разных серверах.

Мне кажется, что вы путаете (вернее смешиваете) OLAP систему с архивом.
1) Все данные попадают в архив
2) Но не все данные загружаются из архива в ОLAP (или все, но с некоторыми процедурами преобразования, дабы можно сделать адекватный кубик)
В своём самом первом топике я, кажется, разделил архив и OLAP. Но не суть важно. Главное, что система так или иначе должна состоять из двух более или менее независимых частей -- в одной данные вводятся и редактируются, и к ней одни требования, а в другой эти данные вытягиваются и анализируются, и к ней совсем другие требования. Вы согласны с этим?