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

[IKA]

Есть форма на основе временной таблицы, она показывает вычисленные значения для каждой номенклатуры(около 15 полей на каждую номенклатуру).
Нужно ограничить количество записей в нее попадающих.
Открывать сразу все, а потом накладывать фильтры - не вариант, тк она 100 лет рассчитываться будет + да и пользователю не нужны все записи. Они бы предпочли сразу указывать критерии,т.е какие номенклатуры им нужно рассчитать и показать.

Как по бест-практис правильней сделать?
Я пока думаю так:
1) класс MyClass- наследник runBase, кот показывает диалог для выбора критериев накладываемых на InventTable. Сформированный запрос по InventTable будет использоваться для ограничения количества номенклатур , попадающих в расчет врем талицы.
2) в его MyClass.run() по

new MenuFunction(menuitemdisplaystr(MyForm),MenuItemType::Display);

открыть мою форму MyForm (кот основана на врем таблице)
3) в init() MyForm через MyClass.parmQuery() достать и передать его в метод MyTmpTable:opulate(), который вставляет (на сервере) записи во врем таблицу и передает курсор обратно в форму.

Все, вроде, хорошо и должно, думаю, работать, но:

1) Может, лучше просто открывать сразу MyForm, но пустой и сделать кнопку на ней для задания критериев inventTable. По OK в диалоге критериев заполнять врем таблицу и заполнять форму данными. Все-таки для аксапты не оч типично запрашивать критерии запроса перед открытием формы.

2) Не лучше ли в классе runBase сразу же заполнять на основе inventTable буфер врем талицы и уже по сути заполненную таблицу передавать в форму MyForm . (а не передавать запрос inventTable в форму , а потом уже в метод MyTmpTable:opulate, как указано выше). Т.о, если класс на сервере выполняется и врем таблица на сервере создается, то мы избегаем передачи запроса по inventTable на клиент в форму MyForm

3)Еще варианты/предложения/альтернативы?

Спасибо

AX2009 RU2

[kashperuk]

Посмотрите, как сделано при открытии формы InventOnHand (list page), которая остатки по номенклатуре показывает.
Перед открытием там (в последних версиях системы) показывается диалог запроса, в котором отфильтровываются записи, после подтверждения открывается сама форма с уже отфильтрованными строками

[IKA]

Прошу прощения, не указала версию: AX2009 RU2
Не вижу формы параметров, когда открываю InventOnHand.
Можете вкратце описать реализацию?

[SRF]

Вариант 1 предпочтительнее, как мне кажется, поскольку он как минимум удобнее для пользователей, ведь что делать пользователю, если он вдруг решил другие номенклатуры посмотреть? Закрывать форму и открывать заново. А если будет кнопка, то можно перевыбрать только нажав на нее и указав другие фильтры, такие реализации есть в системе - например форма в закрытии и коррекции - УЗ\Периодические операции\Закрытие и коррекция\Корректировка, там кнопки в Наличии или Проводки(кнопка выбрать). В стандарте есть и другие места сделанные аналогично.

Вариант 2 тоже имеет право на жизнь, по крайней мере лучше уж сразу заполнять в классе, а не тащить сам квери в форму и там с ним как то возиться.

И еще такой момент, как правило формы с пред фильтром реализованы в узле запросов, например ГК\Запросы\Коды Операций, Банк\Запросы\Банковские проводки, но там постоянные таблицы.

ПС. Форма, о которой писал Иван, использует те же механизмы, что и форма ГК\Запросы\Коды Операций, в форме отображаются данные из постоянных таблиц.

[kashperuk]

Цитата:

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

Прошу прощения, не указала версию: AX2009 RU2
Не вижу формы параметров, когда открываю InventOnHand.
Можете вкратце описать реализацию?

Я бегло глянул, вроде там ничего не придумывали заумного, прям на самой форме сделали, перед выполнением запроса, следующий код:

    //when opening from back/forward (history) do not display query form
    if (this.args().dataset() != tableNum(InventSum))
    {
        queryRunCriteria = new SysQueryRun(inventSum_ds.query());
        queryRunCriteria.promptAllowAddDataSource(false);

        //we display form to modify query criteria in order to mitigate problems with bad performance when large amount of data
        //a user can set up filtering that will be used when the form is opened - this way the user can limit amount of data to be processed
        //the performance problem is due to the query being 'heavy' because of aggregation
        if (queryRunCriteria.prompt())
        {
            inventSum_ds.query(queryRunCriteria.query());
        }
    }
    inventSum_ds.executeQuery();

[sukhanchik]

Цитата:

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

Есть форма на основе временной таблицы, она показывает вычисленные значения для каждой номенклатуры(около 15 полей на каждую номенклатуру).
Нужно ограничить количество записей в нее попадающих.
...
3)Еще варианты/предложения/альтернативы?
AX2009 RU2

Цитата:

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

Форма, о которой писал Иван, использует те же механизмы, что и форма ГК\Запросы\Коды Операций, в форме отображаются данные из постоянных таблиц.

Эх.... Порочная практика применения временных таблиц в том качестве, в котором они не предназначены для применения. По крайней мере в АХ 2009.
Если Вам надо решить задачу с временными таблицами - то вы ее не решите разумным способом за разумное время и так чтобы работало быстро. Будете изобретать велосипед и за ядро пытаться решать сколько записей выводить - так, чтобы было быстро для пользователя.

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

[IKA]

Цитата:

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

Эх.... Порочная практика применения временных таблиц в том качестве, в котором они не предназначены для применения. По крайней мере в АХ 2009..

Я,конечно,почнимаю о чем вы , но если честно, то они именно для этого и предназначены, а подход - все пересчитывать и хранить - это идеологически всегда "средство по бедности" - тк сервер не тянет бытрые расчеты , то придумываются всякие извращенные workarounds.
В случае кубов это оправдано , по идее такие данные как можно было бы вообще с пом view вытянуть
Но, к сожалению, вы правы часто в аксапте используется именно такой подход(

[sukhanchik]

Цитата:

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

Я,конечно,почнимаю о чем вы , но если честно, то они именно для этого и предназначены, а подход - все пересчитывать и хранить - это идеологически всегда "средство по бедности" - тк сервер не тянет бытрые расчеты , то придумываются всякие извращенные workarounds.
В случае кубов это оправдано , по идее такие данные как можно было бы вообще с пом view вытянуть
Но, к сожалению, вы правы часто в аксапте используется именно такой подход(

Это все понятно, но тут-то речь идет не про кубы. Вы сейчас с временной табличкой переливаете данные из постоянной таблички во временную (Вы это делаете на этапе заполнения временной таблицы) и пытаетесь получить производительность у временной таблички такую же, как у постоянной.

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

Кубы это отдельная тема, хотя и со схожей идеей.

[raz]

Ну вместо временной таблицы можно и нормальную таблицу использовать, просто разделять данные разных пользователей по какому то полю. При запуске формы заполнять, при закрытии очищать. Будет и скорость обычной таблицы, и не нужно периодическую опрерацию. В качестве поля для разделения можно использовать код транзакции или связку код пользователя + номер сессии.

[IKA]

Цитата:

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

Я бегло глянул, вроде там ничего не придумывали заумного, прям на самой форме сделали, перед выполнением запроса, следующий код:
[/xpp]

спасибо.

[IKA]

Цитата:

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

. Будет и скорость обычной таблицы, и не нужно периодическую опрерацию.

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

[sukhanchik]

Цитата:

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

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

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

[IKA]

Цитата:

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

А если будет кнопка, то можно перевыбрать только нажав на нее и указав другие фильтры, такие реализации есть в системе - например форма в закрытии и коррекции - УЗ\Периодические операции\Закрытие и коррекция\Корректировка, там кнопки в Наличии или Проводки(кнопка выбрать). В стандарте есть и другие места сделанные аналогично.

Спасибо за пример. Как раз то, что надо!
Хотя сакральный смысл транзакции в InventAdjTransactSelect -> run () мне не ясен (вроде, для врем таблиц ttsbegin - как мертвому припарка, как и проверки на дедлоки). Я так понимаю, просто вслепую шаблоном для runBase->run воспользовались...

+ не совсем не понимаю, почему нельзя было вызвать по menuItemButton этот класс на форме InventAdjTransaction->ButtonGroup->Choose , зачем под кнопкой в clicked пишут prompt() и run() (да и executeQuery на DS можно было бы в классе выполнять)?

[SRF]

Цитата:

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

Спасибо за пример. Как раз то, что надо!
Хотя сакральный смысл транзакции в InventAdjTransactSelect -> run () мне не ясен (вроде, для врем таблиц ttsbegin - как мертвому припарка, как и проверки на дедлоки). Я так понимаю, просто вслепую шаблоном для runBase->run воспользовались...

+ не совсем не понимаю, почему нельзя было вызвать по menuItemButton этот класс на форме InventAdjTransaction->ButtonGroup->Choose , зачем под кнопкой в clicked пишут prompt() и run() (да и executeQuery на DS можно было бы в классе выполнять)?

Можно, но так реализовали, ведь если у вас будет пункт меню клиентский, а сам класс серверный, то разницы(с т.з. механизмы работы), где писать код по вызову prompt, run, executeQuery - в методе на форме или в методе main собственно нет.

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

Цитата:

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Я это к тому (грубые прикидки): что вот форма предположим сейчас открывается 3 часа для 1000 позиций, переделываем на постоянную - получаем скажем 30 минут расчета в пакете, теперь форма для всех позиций открывается 0,5 секунд(но это в случае, если скажем нет необходимости в оперативных данных).

Если мы просто фильтруем рассчитываемые позиции по 10-20, то получаем, что на каждую выборку мы тратим 100-200 секунд, что естественно гораздо больше 0,5, но в тоже время существенно меньше 3 часов.

[sukhanchik]

Цитата:

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

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

Цитата:

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

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

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

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

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

Цитата:

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

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

Цитата:

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

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

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

Цитата:

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

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

Цитата:

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

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

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

Цитата:

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

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

Цитата:

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

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

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

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

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

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

[SRF]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

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

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

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

[sukhanchik]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

[kair84]

2 IKA
Отпишись, сколько времени "стоит" расчет всех полей для 1 номенклатуры.
Есть вариант, при котором для большого кол-ва записей, и относительно недолгого расчета, реализовать без предварительного фильтра и с быстрым открытием.

[IKA]

2 kair84:
Форма открывается 35 секунд на приблизит 1500 записей. Не очень трагично, но неприятно.
Если отключить рассчет полей, то за 3 секунды. Именно поэтому выигрыш от переваливания все в пост таблицу в моем случае не оч очевиднен, тк все съедают именно рассчеты.
Я сделала в результате по предложенному SRF варианту InventAdjTransaction->ButtonGroup->Choose (мне все-таки кажется. что не оч грамотно написанный пример, но рабочий(помимо описанных уже вопросов про неподобающие tts и prompt, также заметила. что там врем таблица "инициализируется" на сервере не вставкой записи , а выборкой ее =) ).

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

SRF - благодарю, за ссылки на готовые примеры реализаций!

[kair84]

Цитата:

Я сделала в результате по предложенному SRF варианту

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