Navision Performace Tips - NAV: Программирование

Eduard-NL · 13.10.2006, 02:59

Спасибо всем за замечания. Несомненно, эта дискуссия будет способствовать лучшему пониманию сути.
Ну а теперь попробую отстоять свою точку зрения.

1. По поводу ключей, используемых исключительно для сортировки.

Цитата:

А как же тогда пользователь будет сортировать?

При работе с SQL Server эти ключи не нужны. SQL производит сортировку без них. Здесь и далее приведу выдержки из SQL Server Resource Kit (см. раздел Minimizing the Impact on SQL Server):

Eliminate the maintenance of indexes that are only designed for sorting purposes. SQL Server will sort the result set without these indexes.

2. По поводу Option Field

Цитата:

Option не обязательно, поскольку это обычное целочисленное поле

Это ограниченный набор целочисленных значений. Помещая Option Field в начале ключа, вы снижаете его селективность. В частности при количестве опций, равном двум, результат будет такой же как в случае Boolean. Предпочтительнее выдвигать вперед Code Field или Integer, если есть такая возможность.

Redesign indexes so that their selectivity becomes higher. Remember to not place Boolean and option fields at the beginning of an index and always put date fields towards the end of the index.
Furthermore, indexes like Posting Date,Customer No.,… must be avoided because the index is like an entire book and the chances that the query optimizer would pick this index are quite small.
Indexes like Document Type,Customer No.,… have very low selectivity on the first key. You could create a new index Customer No.,Document Type, … and maintain it on SQL Server while you turn off the maintenance of the original index on SQL Server.

3.По поводу Не используй FIND(-)/FIND(+), если можно использовать FINDFIRST/FINDLAST.

Цитата:

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

Функции FIND(-)/FIND(+) работают прекрасно с Navision Server, поскольку он использует принцип индивидуального чтения записей ISAM (Indexed Sequential Access Method).
SQL Server пытается определить происходит ли чтение записей в цикле или это всего лишь запрос на единичную запись. Здесь часто возникают проблемы, особенно в случае применения конструкции WHILE FIND('-') вместо REPEAT UNTILL NEXT. Поэтому SQL Server склонен к Set Based Queries и посылать ответ в виде Recordset вместо Single record . Таким образом использование этих функций может быть крайне неэффективным и зачастую снижает Performance. Поэтому начиная с версии 4.00 стали доступны функции FINDFIRST/FINDLAST/FINDSET. Теперь вы можете сделать оптимальный выбор в зависимости от задачи. Вряд ли кто либо воспользуется FIND(+) в известной конструкции:
IF LedgEntry.FIND('+') THEN
NextEntryNo := LedgEntry."Entry No." + 1
ELSE
NextEntryNo := 1;
если гораздо эффективнее FINDLAST.

Что касается преемственности версий, то это совершенно другой вопрос. Microsoft Business Solutions-Navision использует эти функции только в новых, а не модернизируемых обьектах.

4. По поводу Не делай поддержку SIFT в маленьких и временных (Temporary) таблицах.

Цитата:

Вообще ни о чем. Что такое маленькая таблица? при чем тут временная?

Здесь мне кажется все настолько очевидно, что лучше не делать подробного анализа:

Examples of temporary tables are Sales Line, Purchase Line, Warehouse Activity Line, and similar tables. SQL Server can retrieve sums directly from the ‘source’ table when the SIFT indexes are not maintained. If the data set within the filter is small, the sum is calculated quickly and at the same time all the updates of the ‘source’ table are performed more quickly because Navision does not have to update all the associated SIFT tables.

5. По поводу количества ключей в таблице.
Additionally, if you reduce the number of indexes, SQL Server will not have to keep these in memory, thereby increasing page life expectancy and improving performance. Maintaining fewer indexes can mean better performance.

SQL Server Query Optimizer вырабатывает решения на основе накапливаемого опыта запросов. Кстати, он может применить сканирование таблицы даже в случае идеального ключа, если сами записи сильно асимметричны. Не надо "смущать" Query Optimizer большим количеством ключей с одной и той же комбинацией полей.
Необходимо также учитыватьтот фактор что, чем больше ключей, тем больше потери времени на обновление SQL индексов при изменении записей.

6. По поводу Не применяй FlowFields в повседневных, часто используемых формах, тем более в табличных формах..

Цитата:

Собственно почему не применяй? Только из-за вероятности, что пользователь поставит фильтр на вычисляемое поле?

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

7. По поводу

Цитата:

возникают сомнения в понимании автором SIFT технологии

Вот здесь вы правы. У меня точно такие же сомнения. Вот уже семь лет пытаюсь понять, чего больше: вреда или пользы от применения FlowFields в комбинации с SQL Server. Пока безуспешно.

На сегодня достаточно. Пора спать.