Цитата:
Сообщение от
sukhanchik
Но как я понял из исходного поста - проблема-то именно в скорости - а Ваш вариант он просто чисто психологически ускоряет загрузку формы, после чего - скорость расчета не меняется, а проблема решения сколько записей выводить на экран, чтобы не тормозило - остается.
Да, скорость расчета не меняется, но общее время получения нужных данных сокращается. Выводить пользователь может сколько хочет(т.е. он сам в фильтре выбирает нужные номенклатуры для которых нужен расчет), но если будут выбраны все записи, то все будет рассчитываться очень долго.
Цитата:
Сообщение от
sukhanchik
Ну надо признать, что по сравнению с аналогичной временной таблицей - по постоянной все же будет быстрее идти выборка. Да и наличие индексов ускорит выборку по постоянной таблице быстрее.
Да, но в исходном посте речь шла о постоянных таблицах) Возможно Вы подразумевали в сравнении с временными, но из контекста сообщения, это не очевидно.
Цитата:
Сообщение от
sukhanchik
3. Если расчет полей нельзя поставить в пакет - то тут возможны следующие варианты решения задачи по оптимизации:
а) Эмулировать пакет. Т.е. запустить расчет на сервере также, как он запускается, когда запускается из пакета (тут, возможно придется сделать класс-обертку, который делает эту эмуляцию, однако - это будет разовая доработка, применимая ко всем таким ситуациям). Можно получить все преимущества запуска в пакете без постановки задания в пакет.
б) Сделать таблицу, заполняемую онлайн-данными. В определенном смысле - второй InventSum. Этот подход несет в себе конечно кучу рисков, но ... все зависит от постановки задачи. Например, финансовые отчеты, которые формируются генератором отчетности (баланс и т.д.) и которые требуется сделать супер-быстрыми можно реализовать через отдельную табличку, которую заполнять при каждой разноске. Понятное дело, что если дело коснется именно складских проводок и обновления InventSum - то тут рисков больше, чем плюсов. Ну и опять-таки - все зависит от количества одновременно работающих пользователей.
О! Вот он ключевой момент - ускорение предполагается выполнить за счет сокращения исходной выборки данных. Т.е. при скроллинге - расчет будет снова проводиться. На самом деле - такое решение вполне обоснованно имеет место быть. Но... без оглядки на будущее. Потому что следующим пожеланием пользователя будет желание накладывать 100500 видов фильтров и сортировок на выборку. Плюс, как я уже писал выше - вытащить часть этих цифр в 100500 различных отчетов.
В общем-то для нас - специалистов по системе - это хорошо, денежно. Наверное - так и надо делать. Но с т.з. пользователя - это будет негатив на предмет регулярного дергания разработчика по тем действиям, которые раньше он мог делать самостоятельно (накладывать фильтры и сортировку и делать те или иные выборки).
Вот тут не совсем понял, про скроллинг - доп расчетов никаких не будет, если нет каких то дисплей полей, ну т.е. накладывается запрос по таблице inventTable, для выбранных позиций выполняется расчет и они выводятся в грид, надо другие позиции перевыбрали, заново при этом выполнив расчет.
Поэтому, если пакетник сделать нельзя, то мне непонятно как пункт 3.а будет ускорять расчет полей для постоянной таблицы, относительно временной. ну т.е. никто не мешает сделать аналогичный класс обертку для временной таблицы и его использовать в отчетах и т.д. (может быть сложнее в реализации, чем с постоянной таблицей).
И еще по поводу универсальности и пункта 3.б - поддержка такого решения вполне возможно будет проще, возможно какие то отчеты можно будет на основе данного механизма делать - ну т.е. надо будет подправить условно в одном месте, но изначально придется вложиться в эти механизмы в разы больше, чем при решении конкретной задачи, особенно по пункт 3.б, а в результате в реальности этот механизм будет использоваться только в одном месте, поэтому как мне кажется вопрос, что денежнее, не так однозначен)