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

[SRF]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

Вот тут не совсем понял, про скроллинг - доп расчетов никаких не будет, если нет каких то дисплей полей, ну т.е. накладывается запрос по таблице inventTable, для выбранных позиций выполняется расчет и они выводятся в грид, надо другие позиции перевыбрали, заново при этом выполнив расчет.

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

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

[sukhanchik]

Цитата:

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

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

Это все понятно с т.з. разработчика - инструмент правильный. Просто пользователи бывают разные. Я сталкивался с разными типами - с теми, кто готов был предварительно задавать фильтр и с теми, кто все равно сначала выводил все, а потом уже фильтровал. Понятно - что все это лечится воспитанием и рано или поздно люди привыкают к какому-то способу решения своих задач. Тем не менее - достаточно много народа хочет (психологически) видеть все данные, а потом их уже фильтровать (причем, возможно, уже в Excel-е). Поэтому тут нет универсального решения. Там где пользователя (-ей) нужно обрабатывать - то там его (их) уж нужно обрабатывать максимально под минимальную разработку.
Сам вот себя ловлю на том, что мне приятнее просматривать списки в интернет-магазинах целиком, нежели с предварительным фильтром. Конечно может сравнение и неудачное, но тем не менее.

Цитата:

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

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

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

Цитата:

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

Вот тут не совсем понял, про скроллинг - доп расчетов никаких не будет, если нет каких то дисплей полей, ну т.е. накладывается запрос по таблице inventTable, для выбранных позиций выполняется расчет и они выводятся в грид, надо другие позиции перевыбрали, заново при этом выполнив расчет.

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

Цитата:

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

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

Верно, оправданность тут будет только в том случае - если будет один человек, который продумает всю архитектуру и который если и сделает такой механизм, то сделает его только для одного случая. Конечно, если судить тут с т.з. отдельныхТЗ на доработку, которые даются Заказчиком и не брать на себя контроль над всей архитектурой приложения Заказчика - то данный вариант, скорее всего не будет оправдан