Я понимаю OLTP так же, как написано в википедии тынц
первый абзац
авторOLTP (Online Transaction Processing) — онлайновая обработка транзакций. Способ организации БД, при котором система работает с транзакциями небольшими по размерам, но идущими большим потоком, и при этом клиенту требуется от системы максимально быстрое время ответа.
А Вы как, Александр?

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

Наверное, как грится, йа креведко :((
Чтоб мне хоть немного понять Ваши аргументы и объяснения, пожалуйста, приведите пример
Титов Александр приложения, занимающегося отображением данных и Титов Александрприложения, экспортирующего данные

_мод FuzzyСелекты всё ещё не нужны.
Упорно не хотите вводить накладную. Для ввода надо прочитать:
поставщика
договор
товар
ед. измерения
Добавить контроль остатков, оперативный анализ, справки и получите 99% селектов против 1%инсерт-апдейт-делете. Такой вот он олтп понимаешь
Полностью согласен -- OLTP именно такой.
Только всё-таки не нужны селекты, чтобы выбрать поставщика, договор, товар и прочее, если на сервере приложений у нас имеется объектная модель, с которой мы работаем.
Вместо селектов мы отлично используем навигацию по иерархии объектов, что проще, понятнее разработчику и гораздо БЫСТРЕЕ (ведь мы не шукаем постоянно объекты в базе данных по ключам, а просто сразу и непосредственно берём то, что нам нужно, используя объектную ссылку, которая ПРЯМО указывает на нужный объект).

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

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

Чендлер Fuzzy
И всё выше сказанное ООБД проделает на порядок быстрее, чем РБД свои селекты, из результатов которых нужно будет ещё объекты сконструировать.
Доказательства?

Доказательство №1 -- чтобы получить коллекцию по ссылке, ООБД не нужно просматривать хранящиеся данные, т.к. ссылка уже определяет точное местоположение объекта, нужно просто его оттуда взять.
Доказательство №2 -- РБД вернёт набор примитивных типов, да ещё и в виде текста. Из этого добра нужно будет как-то собирать объекты (с учётом уникальности, взаимосвязей и кэширования, что есть форменный дурдом), и соответственно тратить на это время. Ну или забить на объектную ориентированность приложения. А ООБД вернёт уже полностью готовые объекты, ноль проблем.

Титов АлександрВот что нашел по теме: Беседа Марго Зельцер с Майклом Стоунбрейкером
Действительно, забавная статья -- похоже, для OLAP системы РБД тоже не слишком подходит? :))
Ну с этим я не согласен, конечно же.

Титов АлександрДа, тема-то совсем не нова... жмак
Сама тема ООБД ясен пень не нова. Но всегда всё заканчивается так: "а как тут среднее посчитать? ЧТО, ЦИКЛОМ ПО ВСЕЙ КОЛЛЕКЦИИ МЧАТЬСЯ??? Фуу, отстой!".
А я ж и думаю себе: а кому нафих нужно по OLTP-системе средние-то считать? Всё равно для анализа всё в хранилище данных уходит. Ну и какая разница, откуда оно туда уходит, из РБД или из ООБД???
Вот и начал топик это обсудить. Не возражаете?

shelsoft FuzzyВсё равно для анализа всё в хранилище данных уходит

1) не все (оперативные отчеты, ну допустим позволяющие найти ошибку в операционном дне банка до закрытия оного дня)
Согласен, какой-то необходимый минимум отчётов придётся либо сразу предусмотреть в объектной модели, либо делать "программным способом".
shelsoft
2) не сразу и не быстро - Единичный маппинг (как бы сказать одномоментный што-ли, весьма удобно-незаметный, когда пользователь вводит информацию и работает с ограниченным набором сущностей) заменяется на массовый
Это точно, да ведь мы этот массовый маппинг будем делать ночью, когда в базе нет никого. И пусть себе длится часами. В любом случае нужно формировать OLAP кубы для аналитиков. Да и маппинг будет только в направлении объект->реляционное представление, а это куда как проще, чем наоборот.
shelsoft
3) не дешево - неудобно становится уже онализаторам ;o) поскольку изменения в структуре ООБД переливаются в РСБУД, а вот ПО применяемое для анализа (или его настройки) автоматом не делаются
Вот тут не понял. Анализаторы так или иначе работают с теми же самыми OLAP кубами, для них ничего не меняется
______________________________________________________
И говорил мне недавно директор детского сада - "пацан ты шо самый умный, шо больше всех надо" ...
[/quot]