Чистка черновиков или тормоза на форме "Проекты" AX2009 RU5

[Pustik]

У нас есть тестовая база со стандартной логикой. Залили туда некоторые данные из рабочей. Открыл форму "Проекты". И вспомнил как мы столкнулись с жуткими тормозами на этой форме при переходе на АХ2009. При открытии формы "Проекты" на тестовой базе тормоза наблюдаются, но не такие заметные, так как данных мы залили не много. А на рабочей с реальными данными просто жуть.
А все потому, что в табличке ProjTable есть метод:

public boolean trxExists()
{
    ProjId                  projId = this.ProjId;
    boolean                 ret = true;

    ProjJournalTrans        projJournalTrans;
    LedgerJournalTrans      ledgerJournalTrans;
    InventJournalTrans      inventJournalTrans;
    ProjTransPosting        projTransPosting;
    SalesLine               salesLine;
    PurchLine               purchLine;
    SMAAgreementTable       smaAgreementTable;
    SMASubscriptionTable    smaSubscriptionTable;
    ProjRevenueTrans        projRevenueTrans;
    ProjOnAccTrans          projOnAccTrans;
    SMAServiceOrderLine     smaServiceOrderLine;
    PurchReqTable           purchReqTable;
    PurchRFQCaseTable       purchRFQCaseTable;
    ;

    if (this.Header == NoYes::No)
    {
        if(((select firstonly projJournalTrans      where projJournalTrans.ProjId        == projId).RecId == 0) &&
           ((select firstonly ledgerJournalTrans    where ledgerJournalTrans.AccountNum  == projId &&
                                                          ledgerJournalTrans.AccountType == LedgerJournalACType::Project).RecId == 0) &&
           ((select firstonly inventJournalTrans    where inventJournalTrans.ProjId      == projId).RecId == 0) &&
           ((select firstonly projTransPosting      where projTransPosting.ProjId        == projId).RecId == 0) &&
           ((select firstonly salesLine             where salesLine.ProjId               == projId).RecId == 0) &&
           ((select firstonly purchLine             where purchLine.ProjId               == projId).RecId == 0) &&
           ((select firstonly smaAgreementTable     where smaAgreementTable.ProjId       == projId).RecId == 0) &&
           ((select firstonly smaSubscriptionTable  where smaSubscriptionTable.ProjId    == projId).RecId == 0) &&
           ((select firstonly projRevenueTrans      where projRevenueTrans.ProjId        == projId).RecId == 0) &&
           ((select firstonly projOnAccTrans        where projOnAccTrans.ProjID          == projId).RecId == 0) &&
           ((select firstonly smaServiceOrderLine   where smaServiceOrderLine.ProjId     == projId).RecId == 0) &&
           ((select firstonly purchReqTable         where purchReqTable.ProjId           == projId).RecId == 0) &&
           ((select firstonly purchRFQCaseTable     where purchRFQCaseTable.ProjId       == projId).RecId == 0) &&
           (!this.AssetId))
        {
            ret = false;
        }
    }
    else
    {
        ret = false;
    }

    return ret;
}

он дергается из метода на форме setFieldAccess(), а этот, в свою очередь, стоит в методе active() у главного датасоурса: ProjTable.
Сразу скажу, что мы приняли решение во все таблицы добавить индех по полю ProjId, а в таблицу LedgerJournalTrans по AccountNum,AccountType.Скорректировали запросы в этом методе на IndexHint и все зашуршало.
В основном тормоза были на таблицах projJournalTrans,LedgerJournalTrans,inventJournalTrans,SalesLine,PurchLine. Эти таблицы, можно сказать являются справочниками-черновиками. Вся главная информация лежит в проводках. И у меня возникает вопрос: разработчики не обратили на скорость внимание рассчитывая на то, что черновики периодически должны чиститься или просто не подумали? Но главный вопрос вообще о целесообразности чистки черновиков. Кто-нибудь чистит эти таблицы? У нас эти таблицы не чистятся. Записей очень много.
PS: Тему может быть неудачно назвал. Но ведь можно было назвать и так "Чистка черновиков и Экономия место БД" или как-то еще. Решил так как есть, так как задумался об этом на форме.

[lev]

я в шоке от кода! это на слое SYS?

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

if (ProjTable.hasProjJournalTrans()     &&
    ProjTable.hasLedgerJournalTrans() &&
    ProjTable.hasInventJournalTrans() && ...)

+
Хочется добавить, что этот код так же попытались с оптимизировать. Ведь конструкция типа:

(select firstonly projJournalTrans      where projJournalTrans.ProjId        == projId).RecId

позволяет не использовать переменные, что сокращает размер выделяемой памяти под переменные и ускоряет выполнение запроса, минуя переменные.
Но в начале метода все переменные объявлены! И по сути потом нигде не используются!

В общем я опять в шоке от кода от компании Microsoft

[Владимир Максимов]

Цитата:

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

В основном тормоза были на таблицах projJournalTrans,LedgerJournalTrans,inventJournalTrans,SalesLine,PurchLine. Эти таблицы, можно сказать являются справочниками-черновиками. Вся главная информация лежит в проводках. И у меня возникает вопрос: разработчики не обратили на скорость внимание рассчитывая на то, что черновики периодически должны чиститься или просто не подумали?

Скорее всего, просто не подумали. Точнее, ошибки тестирования.

Кстати, IndexHint я бы использовать не советовал. Индексы должны подхватится и без них, а сам факт использования хинтов, принуждающих сервер к чему-либо, может выйти "боком" при дальнейшем развитии системы.

Цитата:

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

Но главный вопрос вообще о целесообразности чистки черновиков. Кто-нибудь чистит эти таблицы? У нас эти таблицы не чистятся. Записей очень много.

Зависит от того, как они используются.

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

Другими словами, все крутится вокруг отчетности. Если для составления справок и отчетов эти документы не нужны, то и хранить их нет необходимости.

[Pustik]

Цитата:

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

Хочется добавить, что этот код так же попытались с оптимизировать. Ведь конструкция типа:

(select firstonly projJournalTrans      where projJournalTrans.ProjId        == projId).RecId

позволяет не использовать переменные, что сокращает размер выделяемой памяти под переменные и ускоряет выполнение запроса, минуя переменные.

Я про это не знал..Спасибо.

[Pustik]

Цитата:

Сообщение от Владимир Максимов

Зависит от того, как они используются.
Кто-то уже высказывался в том духе, что как правило, при кастомизации, исходные заказы/закупки/журналы получают ряд дополнительных характеристик (полей), которые не транслируются в проводки. Как следствие, чтобы получить отчеты в разрезе этих характеристик возникает необходимость обратится к этим самым "черновикам"
Другими словами, все крутится вокруг отчетности. Если для составления справок и отчетов эти документы не нужны, то и хранить их нет необходимости.

Все просто и понятно. Есть места, где используем дополнительные характеристики, а есть и где не используем.Там где не используем, удалять пока боимся . Хотел услышать от кого-нибудь "как плохо жить", если эти черновики не удалять. Пока негатива нет.Так что будем сохранять.

[Владимир Максимов]

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

Если нет проблем с дисковым пространством, то лично я не вижу причин их удалять. Удаление чего-либо - это всегда риск. Всегда остается некое сомнение "а вдруг понадобится"