Оптимизация кода с LedgerTrans

[glibs]

Цитата:

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

...
запрос будет целиком исполняться на SQL-сервере
...

А что в данном контексте нужно понимать под термином "запрос"?

[mazzy]

Цитата:

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

А что в данном контексте нужно понимать под термином "запрос"?

текстовая строка "Select <Бла-бла-бла> from <Бла-бла-бла> ...", которая выполняется НА СЕРВЕРЕ.

поскольку у таблицы LedgerTrans переопределен метод postLoad, то умная Аксапта не посылает SQL-серверу запрос с просьбой посуммировать, а выбирает все записи по одной, применяет к каждой метод postLoad и суммирует сама.

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


Так вот. Русские отчеты написаны неправильно. Они не учитывают "особенность" таблицы LedgerTrans и суммируют "от начала времен". Что приводит к выборке в Аксапту каждой проводки из LedgerTrans, которая попадает в условие.

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

[raz]

Цитата:

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

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

спорить не буду, но вот такой job:

static void Job1(Args _args)
{
    ledgertrans     lt;
    ;
    select sum(amountmst) from lt where lt.AccountNum == "zzz";
    print(lt.AmountMST);
    pause;
}

дал такой эффект (количество записей в LedgerTrans 8933031 количество суммируемых записей 438868)