Собственно начало разбора тут: v8: Динамическое считывание данных. В чем польза?

кратко: есть что то типа "журнала" - такая аналитическая таблица куда собирается мегасложным запросом куча данных по заказам с выкладкой о состоянии.
по сути - что то типа динамического определения статуса заказа в производстве.

наткнулись на несколько интерфейсных багов описанных в вышеуказанной ссылке.

Продублировав функциональность журнала как в динамическом списке так и в табличной части обработки так и в таблице значений выяснилось что для "листания" самое удобное таблица значений.
Что собственно и неудивительно - один раз напряглись и далее листаем журнал сколько нам нравится.

Теперь всплыл баг номер два: время затраченное на обновление журнала и соответственно подвисание всего окна в момент обновления.

Сейчас журнал заполняется 4 секунды запросом (тестирую на небольшой базе собирая все за год, агрегаты выключены).

Суть ситуации: родилась идея и была воплощена  в том что а почему бы не собирать данные фоновым заданием а на клиенте только брать из хранилища результаты и отображать их?

Сделал.
две обработки ожидания - одна пускает фоновые задания по обновлению данных, вторая проверяет факт обновления и загружает их в ТЗ.

Работает заметно быстрее тупого запроса инициированного с клиента.


Собственно вопрос: ктонить замарачивался подобным? где могут быть подводные камни?

(0) ты родил OLAP - поздравляем =)

(1) от черт..

теперь чо, переделывать обратно?

Если ты пишешь мегасложный запрос, то ты семерочник. Восьмерочник обязан нагородить мегасложный регистр (или несколько), а запросом только выкатывать его содержание пользователю

(4) бгыы

дык я и нагородил дофуя мегасложных регистров..
теперь их надо все в одном журнале показать, так сказать сводно..

вот это то и тормозит

Закладка

(3) зачем переделывать, фоновая трансформация данных технология нужная и ты её использовал по месту

вопрос в том, как разделить статическую и динамическую часть данных, что кэшировать, а что нет

(5) Значит, простые у тебя регистры и в запросе много считать приходится. В идеале должен быть запрос "выбрать * из мегарегистр", а там уже все готовое должно быть. А чтоб готовое было - рассчитывать фоновой обработкой, типа проведения по партиям. Что-то подобное ты и сделал, но как-то излишне ректально

(7) в том что и ж.па что все данные динамические..
в этом и суть журнала - манагеры сидят и пырятся в него с утра до вечера..

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

(8) пробовал..
была мысль положить все содержимое в регистр а потом выводить практически один в один.
все уперлось в две проблемы:

1. периодичность обновления регистра (нужна манагерам возможность чо то поменять затем жмакнуть и мгновенно увидеть изменения в журнале)

2. работа в файловой версии в конторах где все тупорылы.

(9) если все данные динамические,то ты выигрываешь за счёт распараллеливания и упреждающей выборки


но тогда встает очевидный вопрос из (8)
что мешает делать движения по финишному регистру на уровне проведения документов

(10) а фоновое задание в файловой тебя не пугает, оно же будет таскать на клиента мегаобъём данных ?

(11) не очень хочется все завязывать на один регистр..
система то многопользовательская..

кто то материалы списывает а какой то робот доставку с почты считывает...

сейчас каждый в свое пишет и все счастливы..

(12) ыы не.. там я заглушку поставил - тупое обновление запросом "как обычно"

и что там выводится ? Пульс пользователей есть ?

(15) типа тово.. и температура с беспроводных ректальных градусников...

а пользователи на них сами садятся или специалист какой их вставляет ?

(17) запускаешь 1С
а там при начале работы системы покдлючение к внешнему устройству через ком..

и оно уже из сиденья стула выдвигает термометр..

а девушки не жалуются ? у них не туда может законектится ?

(19) девушки очень усидчивые сотрудники...

не, все же раскрой тайну, что же ты там выводишь

(21) в ссылке из (0) был вроде скриншот..
лень заново делать.. там можно подглядеть

понятно, красота , за это надо сражаться :) может когда нибудь в зале решелье выставят

(23) нудк.. манагеры  к хорошему привыкли... теперь их фиг отучишь...