Ограничение выборки перед открытием формы - как лучше сделать?

[sukhanchik]

Цитата:

Сообщение от sukhanchik

Если Вам надо решить задачу с временными таблицами - то вы ее не решите разумным способом за разумное время и так чтобы работало быстро.

Цитата:

Сообщение от SRF

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

Вот вариант начальной реализации - открывалась форма и по всем номенклатурам начинался расчет, действительно не лучший вариант использования временной таблицы, но меняем реализацию на открытие пустой формы, добавления кнопки расчета - реализация не займет много времени, способ не разумный? или медленно работать будет ? Полный расчет для временной и постоянной таблицы на всем объеме данных будет сравним(как я понимаю, потому что основное время отъедает именно расчет полей), единственным по сути отличием будет то, что задание для постоянной таблицы можно поставить в пакет, НО это еще при условии, что в форме не нужно отображение актуальных данных, а-ля цена, остатки, еще что нибудь, в противном случае мы и в пакет то задание поставить не сможем.

Вот тут как раз кроются те нюансы, которые можно вложить в слово "разумные" в мою фразу.
1. В общем-то я говорил - что разница между переливом во временную таблицу и постоянную - небольшая. (Можно даже считать, что ее нету, хотя до тех пор, пока временная таблица не находится под управлением СУБД - я думаю - что разница будет заметна). За исключением возможности использовать класс RecordInsertList, что дает существенный прирост в скорости.
2. Если расчет полей (т.е. вышеуказанный перелив) можно поставить в пакет - то это будет быстрее в первую очередь психологически. Т.е. если нет потребностей видеть актуальных данных (пример которых Вы привели), то гораздо лучше (с т.з. пользователя) сделать периодическую операцию, которая предварительно рассчитывает данные, а уже форма быстро их выводит. Т.е. не будет негатива от пользователей - что форма тормозит при открытии. Ну и само собой пакетник будет быстрее считать - это я думаю понятно.
3. Если расчет полей нельзя поставить в пакет - то тут возможны следующие варианты решения задачи по оптимизации:
а) Эмулировать пакет. Т.е. запустить расчет на сервере также, как он запускается, когда запускается из пакета (тут, возможно придется сделать класс-обертку, который делает эту эмуляцию, однако - это будет разовая доработка, применимая ко всем таким ситуациям). Можно получить все преимущества запуска в пакете без постановки задания в пакет.
б) Сделать таблицу, заполняемую онлайн-данными. В определенном смысле - второй InventSum. Этот подход несет в себе конечно кучу рисков, но ... все зависит от постановки задачи. Например, финансовые отчеты, которые формируются генератором отчетности (баланс и т.д.) и которые требуется сделать супер-быстрыми можно реализовать через отдельную табличку, которую заполнять при каждой разноске. Понятное дело, что если дело коснется именно складских проводок и обновления InventSum - то тут рисков больше, чем плюсов. Ну и опять-таки - все зависит от количества одновременно работающих пользователей.

Конечно главный критерий время и удовлетворенность пользователя.. Т.е. если объем данных позволяет выбрать Ваш вариант - не вопрос. Но как я понял из исходного поста - проблема-то именно в скорости - а Ваш вариант он просто чисто психологически ускоряет загрузку формы, после чего - скорость расчета не меняется, а проблема решения сколько записей выводить на экран, чтобы не тормозило - остается.

Цитата:

Сообщение от sukhanchik

Будете изобретать велосипед и за ядро пытаться решать сколько записей выводить - так, чтобы было быстро для пользователя.

Цитата:

Сообщение от SRF

А что плохого в том, что мы будем решать за ядро сколько записей выводить ? Если нам не надо получать всю информацию, а нужны только определенные данные, вполне можно использовать как один из возможных вариантов оптимизации.

Отсутствие универсальности. Пользователи разные, объем данных будут хотеть смотреть разный, фильтры разные захотят использовать. Техника плюс-минус разная.
И еще один важный момент. Все пользователи, когда хотят дать задание на доработку - ориентируются на существующие цифры в системе. Т.е. сегодня Вы с большим трудом оптимизировали форму, которая рассчитывает цифры, а завтра Вам сказали - что хочется часть этих цифр видеть там, там и вооон там (среди различных источников данных). Плюс применить к ним какие-то арифметические действия. При наличии предрасчитанных данных - Вам будет легко на них сориентировать новые запросы. В противном случае - Вы тормоза при расчете протянете в каждое место системы, где пользователь захочет видеть цифры. Ну или будете опять переделывать форму, за которую уже отчитались.

Цитата:

Сообщение от sukhanchik

Ну а форма, основанная на постоянной таблице - будет открываться быстро на любом объеме данных - это уже стандартное поведение ядра системы.

Цитата:

Сообщение от SRF

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

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

Цитата:

Сообщение от sukhanchik

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

Цитата:

Сообщение от SRF

Да эффект будет, но если основное время при открытии формы занимает расчет полей, что как я понимаю в данной задаче и является основной проблемой - то почему бы быстро не уменьшить объем рассчитываемых данных ?

О! Вот он ключевой момент - ускорение предполагается выполнить за счет сокращения исходной выборки данных. Т.е. при скроллинге - расчет будет снова проводиться. На самом деле - такое решение вполне обоснованно имеет место быть. Но... без оглядки на будущее. Потому что следующим пожеланием пользователя будет желание накладывать 100500 видов фильтров и сортировок на выборку. Плюс, как я уже писал выше - вытащить часть этих цифр в 100500 различных отчетов.

В общем-то для нас - специалистов по системе - это хорошо, денежно. Наверное - так и надо делать. Но с т.з. пользователя - это будет негатив на предмет регулярного дергания разработчика по тем действиям, которые раньше он мог делать самостоятельно (накладывать фильтры и сортировку и делать те или иные выборки).

Мне казалось, что такой подход как раз является неразумным, с т.з. времени, которое будет тратиться на обслуживание этой формы и то, чего из нее выросло и расползлось. Т.е. я считаю в данном случаем под временем не только время на решение конкретной задачи на оптимизацию формы, но и время, потраченное в дальнейшем на решение связанных задач, которое потенциально может быть увеличено из-за выбранного способа оптимизации формы.

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