gardenman

ОК! я прекрасно понимаю о чем вы говорите.
Если получать остатки по 3 счетам (или даже 100) то такой запрос отрабаты вает достаточно быстро и как правило - баланс сходится. Но если счетов будет пара сотен - то баланс не попрет. Поэтому в блокировочнике поступают следующим образом: берут остатки на начало дня (а они неизменные) и прибавляют к ним обороты. И оказывается что баланс как ни странно все равно сходится...:((
Чтобы прибавить обороты - выгружаем все проводки (Дб,Кд,Сумма) во временную таблицу (типа снапшот делаем - можно в режиме UR) и потом накатываем на остатки на начало дня. Согласен - это несколько труднее чем тупой селект по остаткам. Но, я уже говорил вам - такая хрень и этот отчет понадобится ну разве что идиоту которому нефиг делать кроме как смотреть как меняются цифирки на экране в реальном времени, и давить на клавиши каждые пять минут чтобы увидеть как они эти цифирки меняются.

А если меняющих одновременно и строящих отчеты пусть десятки, (у нас где то так),

и как мне надо будет объяснить тем десяткам людей, которые как раз нажимают кнопочки, и смотрят каждые "5 мин", что они идиоты?

Да часть данных которые мы можем себе позволить, для ускорения работы, выгружаются из OLTP и аггрегируються в что то типа DWH, но оно тоже пересчитываеться каждый час,
и что на время этого пересчета, всем кто изменяет данные в OLTP и делает отчеты по этому DWH тоже сидеть и ждать?

gardenmanЗачем человеку нужно отслеживать баланс каждые пять минут? ну?....
И это нужно разве что - главбуху.. да и то на момент закрытия квартала, когда делают заключительные обороты. Да и то, заключительные обороты делают в прошедшим днём.

Реальное время? хе!!! пока вы вормируете отчет - данные уже уехали далеко! какое нафиг реальное время? Вообще "реальное время" по отношению к базам данных - понятие очень растяжимое. Вы всего лишь получаете срез на конкретный момент времени. А о реальном... Дорогой друг! тут тока uncommited read поможет ... А у оракла с этим туго....


Затем, что данные нужны КОРРЕКТНЫЕ, что бы суммы (и прочие операции) по строчечкам и столбикам (см. выше мой пример, хоть в жизни данные и операции гораздо сложнее), СОВПАДАЛИ.
(простые отчеты в нашей системе строятся где то от 0 до 5 мин, за несколько минут данных может поменяться ой как много, и нужно что бы они менялись, без задержек, а результаты отчетов все равно были правильными)

Шутки шутками, а в пределах 1 запроса, для достижения этого результата ораклу достаточно его READ COMMITED (хот может и не очень "честного" в понимании других СУБД), и uncommited read ему просто не нужен, потому что толку от него быть неможет , а вред может, это уже много раз обсуждали.

У нас сеть супермаркетов, название приложения врядли вам чтото скажет, да и какая разница, специфика бизнеса довольно типичная.

ggv --- менеджер очередей --- ну и еще по требованию может кое-что использоватся.

А вы не задумывались, что в Оракле это и еще кой чего может быть просто не нужно, одной базы достаточно?


ggvВсе равно все упрется - а вет если "select * from table" когда на нее падают транзакции, то все будет тормозить - вот с этим в сад. Не видел я ни в одном проекте таких запросов.

А если понадобися такое? то что тогда?
А в Оракле бери и делай.

ggvИ подтверждение моих слов - результаты формальных тестов.
Если задача формально определена, то блокировочники показывают хорошие результаты.

Ээх, если бы мир был идеален, и все всё делали правильно, вовремя, семь раз думали прежде чем отмерять и т.д. ....


А мне еще приходится сталкиваться с задачами типа "это должно быть сделано вчера", и такими о которых вчера еще никто и подозревать не мог.