i-neti: Топ 10 проблем, обнаруженных при проверке кода в Dynamics AX

[Blog bot]

Источник: http://i-neti.ru/blog/203
==============

Три года назад, наша команда (Premier Field Engineer) приступила к проверке кода Dynamics AX для ключевых клиентов. Это было довольно интересно, в связи с множеством модификаций различных проектов.

подробнее



Источник: http://i-neti.ru/blog/203

[Napalm]

Цитата:

3. Большие и ресурсоемкие запросы связанные с выборкой всех полей таблицы

Это возможно самая распространенная проблема имеющая большое влияние на производительность, но в то же время ее проще всего обнаружить и исправить. Используйте Exist Join и перечисление полей, всегда когда это возможно. Убедитесь, что в каждой выборке в коде указаны только необходимые поля. Та же идея с использованием exist join в выборке когда это возможно, для уменьшения объема данных передаваемых между AOS и базой данных. Это особенно актуально когда при модификации на существующие таблицы добавляется много новых полей.

Например, код:

While select TableA
              {  Select TableB where TableB.FieldA == TableA.FieldA;
                 Print TableB.FieldB;
              }

Заменить на следующий:

              While select FieldA from TableA Join FieldA, FieldB from TableB
              Where TableB.FieldA == TableA.FieldA;
              {
   Print TableB.FieldB;
              }

Ай да молодцы! Ай да пофиксили!

[macklakov]

Цитата:

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

Ай да молодцы! Ай да пофиксили!

Для меня операторы, начинающиеся с большой буквы, признак больших проблем в коде. Точно не знаю, откуда приходят эти люди, но код они повреждают в примерно одинаковом стиле. Особенно ужасно их "улучшения" сказываются на производительности. Именно после них удается показывать чудеса оптимизации на 2 порядка чисто правкой X++.

[Link]

Цитата:

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

Точно не знаю, откуда приходят эти люди, но код они повреждают в примерно одинаковом стиле.

Я знаю от куда, как раз работаю у индусов, могу познакомить

[fed]

Говоря о сути проблемы: Чтобы там не писалось в best practice, на мой взгляд, перечисление выбираемых полей в select имеет смысл только в двух случаях:
1. Есть покрывающий индекс (и мы боремся за скорость какого-то очень часто выполняющегося запроса).
2. Массово выбираем данные из какой-то очень разбухшей таблицы (то есть - больше 20-25 полей и выбираем тысячи, а не десятки записей).
Во всех остальных случаях - экономия нескольких килобайт трафика между AOS и сервером БД не покроет потенциального гемора с попыткой доступа к непрочитанному полю при быстром латании кода.

Ну и конечно - если ни одно поле из таблицы вообще не используется - ей самое место в exists join или в join tableid from table.

[trud]

Цитата:

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

1. Есть покрывающий индекс (и мы боремся за скорость какого-то очень часто выполняющегося запроса).

а вот с покрывающимися индексами в 2012 сделали большую засаду, независимо от указанного списка полей выбирается RecId, неизвестно как бороться с этим

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

[Logger]

Цитата:

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

а вот с покрывающимися индексами в 2012 сделали большую засаду, независимо от указанного списка полей выбирается RecId, неизвестно как бороться с этим

Не пробовали группировку добавить по отбираемым полям ?
По идее план запроса не должен ухудшиться - все равно по индексу пойдет перебор.

[Vadik]

Цитата:

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

а вот с покрывающимися индексами в 2012 сделали большую засаду, независимо от указанного списка полей выбирается RecId, неизвестно как бороться с этим

Назначать кластерным индекс по RecId

[Удвой Покуров]

Хорошо что ребята хоть разбираются. А то обычная проблема номер 1 при аудите: посмотрели код, не поняли что за язык, стали судорожно звонить менеджеру.