Nav5 работа с полями FlowField и циклы - NAV: Программирование

Drug · 18.02.2011, 17:13

Добрый день, коллеги!
Стоит Nav4.3, надо перейти на Nav5. По мне так лучше сразу Nav2009, не суть.
Сделал с рабочей базы 2 тестовые, одну оставил на 4.03, вторую конвертировал под 5.01 (все на одном серваке SQL2005).
Запускаю самописный отчет, выгрузка в Excel, суть отчета "по каждому товару выгрузить за период "начало, приход, расход, остаток" в количестве и в деньгах, плюс все это по каждому складу/зоне/ячейке. Все сделано на Calcsum, удобно, просто и вроде быстро работает.
Так вот, стоит задача оценить производительность Nav5!
1 вариант: База просто конвертирована. Отчет на Nav5 делается медленнее.
2 вариант: Почитал форумы. Открываю таблицы 32, 5802... удаляю все ключи. Создаю в таблицах по одному новому ключу (поля в ключе по сути повторение полей моих фильтров в отчете). Ну и мелочи, FINDSET везде сделал в отчете. Запускаю отчет, засекаю время. Делается по времени также как и на 4.03, что уже не плохо.
Вот скажите плс, получается в моем случае отличия в Nav4 от Nav5 только:
1. в увеличении скорости операций записи и удаления, за счет создания и обновления только одной таблицы с "моим длинным ключем"?
2. Calcfild и calcsum будут медленнее работать в случае "редких" фильтров, так как раньше можно было сделать например 2 разных ключа и посчитать итоги, а теперь один длинный ключ, который надо еще отфильтровать?
3. Я ошибался что в Nav5 были оптимизированы запросы к SQL серверу, тем самым убыстрив операции чтения/удаления/записи?
4. Интересно (в случае Nav5) какой ключ "целесообразный" в таблицах 32 и 5802. Интересно в случаях записей в таблицах более миллиона, да и пользователей под 100 человек.

Спасибо!

rmv · 21.02.2011, 12:53

1. Да
2. С уходом бакетов (sift-levels to montain) изменились правила игры с вычисляемыми полями. Представьте ключ из десяти поле Field1..Field10. Раньше - sift-levels to montain стоит на всех уровнях, наложили фильтр по Field1, sumindexfield просчитался мгновенно, селективность идеальная, т.к. есть соотвествующий уровень и записи расположены по порядку, наложили фильтр по Field10 - селективность самая низкая, sumindex field будет считаться долго. С появлением индексированных представлений запросы фильтром что по Field1, что по Field10 будут выполнятся практически одинаково (по Field1 возможно несколько быстрее в силу страничного расположения индекса). В общем случае рекомендация - по возможности разбивайте длинные ключи на более короткие.
4. Точно не такой же что и в более ранних версиях. Экспериментируйте.

К сожалению, сказав А и изменив подход к sift ключам в SQL версии, разработчики MS не сказали Б и не оптимизировали ключи для работы в новых условиях, и, насколько мне известно, даже не выдали рекомендации.
К примеру, устаревшее правило хорошего тона задвигать Posting Date в конец ключа (в старых версиях индексы по дате могли монтироваться в т.ч. по месяцу и году, что могло породить дублирование на более низких уровнях) приводит к низкой селективности и как следствие существенному замедлению отчетов по оборачиваемости.
Возможно причина в том, что подход к формированию ключей для SQL версии и native DB должен быть различным, и MS пока не спешит пересаживатся со стула Native DB.

rmv · 21.02.2011, 12:56

Дубль

Drug · 05.05.2011, 18:38

Цитата:

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

Спасибо, очень информативно, мне помогло.
Но есть вопрос. Вы говорите по возможте создавать несколько мелких ключей, разве мы этим не увеличим время на выборку по фильтру из таблицы с промежуточными значениями?
Поясню по пунктам:
1. Теперь в Nav5 создается одна таблица с SumIndexField
2. Допустим в моей таблице 5 разных ключей с SumIndexField
3. Делаю SETCURRENKEY(Key3), потом SETRANGE(Field3,MyFilter3) и расчитываю CALCSUM(Qty)
4. Таким образом сначала необходимо будет отфильтровать таблицу по ключу, а потом посчитать сумму.
5. Не лучше создавать один длинный ключ?

rmv · 10.05.2011, 14:27

Цитата:

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

Но есть вопрос. Вы говорите по возможте создавать несколько мелких ключей, разве мы этим не увеличим время на выборку по фильтру из таблицы с промежуточными значениями?
Поясню по пунктам:
1. Теперь в Nav5 создается одна таблица с SumIndexField
2. Допустим в моей таблице 5 разных ключей с SumIndexField
3. Делаю SETCURRENKEY(Key3), потом SETRANGE(Field3,MyFilter3) и расчитываю CALCSUM(Qty)
4. Таким образом сначала необходимо будет отфильтровать таблицу по ключу, а потом посчитать сумму.
5. Не лучше создавать один длинный ключ?

Не совсем понял пример по пунктам, попробую пояснить свою мысль на крайнем случае.
Представьте себе - жил был длинный ключ с сифтами на таблице Value Entry из 10 вообщем-то нужных полей и тут ~~skipped~~ недальновидный программист решил добавить в конец ключа поле Entry No. - то бишь первичный ключ таблицы. Как же это безобразие отразиться для Нав 4 и Нав 5?
Нав 4 - под новый уровень добавит число записей, равное числу записей в таблице Value Entry. Вообщем-то отчеты в производительности не потеряют, так как селективность практически не поменяется. Сильно проиграет учет, так как вынуждет будет обслуживать доп. уровень.
Нав 5 - тут трагедия. Число записей в индексированной вьюхе ставит равной числу записей в таблице Value Entry. Немного проиграет учет, а вот отчеты вместо обработки агрегированных данных будут лопатить по сути ту же Value Entry.
Резюме для Нава 5 такое - чем больше записей в индексированном представлении, тем медленнее работает расчет сифт полей. Если есть возможность уменьшить число записей в индексированном представлении - следуюет ею воспользоваться, один из вариантов - по возможности разбивать ключ на более мелкие.
PS. Есть варианты ускорить расчеты сифтов на пару порядков, например перестроя порядок полей в ключе и используя покрытые индексы. Очень хочется верить что в новой версии платформы MS в наконец то откажется от поддержки натив ДБ и использует все преимущества SQL сервера.

Drug · 13.05.2011, 13:15

Респектище!