AX2012: После прочтения документа по изменениям в inventTrans, борюсь с непреодолимым желанием уйти в запой на недельку

[Ievgenii]

Цитата:

Передай большое человеческое спасибо разработчикам модуля логистики

Эта фраза как тут говорять - make my day Обязательно передам.

Цитата:

борюсь с непреодолимым желанием уйти в запой на недельку

Это понятно - в общем с первого взгляда новая версия от всех до нее версий сильно отличаються. С другой стороны не так страшен черт как его рисуют . В этом случаи инвент транс* normalized по сравнению с ax2009, что дает улутшения по производительности в целом + много плюсов для архитекруты системы (не говоря уже какое количество багов было пофикшено по ходу).

Эти доки - только самые первые, я думаю далеко не все моменты были освещены, по этому не стоит спешить с выводами.

Все что не делаеться - делаться только на благо (или покрайней мере с найлутшими намериниями).

[sukhanchik]

Цитата:

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

В этом случаи инвент транс* normalized по сравнению с ax2009, что дает улутшения по производительности в целом

Это с каких это пор нормализация давала улучшения в производительности? Наоборот - выборка из одной денормализованной таблицы гораздо быстрее, чем из пачки мелких.
Другое дело, что в АХ исторически сложилось писать select * from таблица, т.е. выбирать все поля, а не поштучно. Это конечно удобно для разработчика, но с т.з. быстродействия все же лучше в коде указать список полей для выборки, нежели "пилить" таблицу.
Посмотрим конечно - но уже сейчас на форуме то и дело проскакивают сообщения об общей тормознутости АХ 2009 после АХ 4.0 и тем более 3.0.
Уже страшно предположить что будет в АХ 2012 на реальных данных.

Цитата:

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

Все что не делаеться - делаться только на благо (или покрайней мере с найлутшими намериниями).

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

Особенно мне понравился тот факт (это из другого документа), что хотя в АХ 2012 и не отказались от RLS - от него планируется отказаться в будущих версиях. Оно и понятно - отчеты на SSRS тяжело строить с проверкой всех прав. Но .... это ж ключевая технология - как от нее отказываться?

[imir]

Цитата:

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

Но .... это ж ключевая технология - как от нее отказываться?

А зачем RLS, когда можно создать 100500 таблиц клиентов и товаров.
Dax 12 - почувствуй нашу любовь %)

[mifi]

Цитата:

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

Это с каких это пор нормализация давала улучшения в производительности? Наоборот - выборка из одной денормализованной таблицы гораздо быстрее, чем из пачки мелких.
Другое дело, что в АХ исторически сложилось писать select * from таблица, т.е. выбирать все поля, а не поштучно. Это конечно удобно для разработчика, но с т.з. быстродействия все же лучше в коде указать список полей для выборки, нежели "пилить" таблицу.
Посмотрим конечно - но уже сейчас на форуме то и дело проскакивают сообщения об общей тормознутости АХ 2009 после АХ 4.0 и тем более 3.0.
Уже страшно предположить что будет в АХ 2012 на реальных данных.



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

Особенно мне понравился тот факт (это из другого документа), что хотя в АХ 2012 и не отказались от RLS - от него планируется отказаться в будущих версиях. Оно и понятно - отчеты на SSRS тяжело строить с проверкой всех прав. Но .... это ж ключевая технология - как от нее отказываться?

Поскольку SSRS отчеты уже построили в ax 2012, то они здесь роли не играют. Если пользоваться стандартными средствами для построения SSRS отчетов, то все должно быть хорошо с RLS
Вместо RLS предлагается Extensible Data Security Framework (XDS), который, в общем, похож на RLS по принципу работы, но требует модификации соответствующих Policy в AOT

[fed]

Цитата:

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

Другое дело, что в АХ исторически сложилось писать select * from таблица, т.е. выбирать все поля, а не поштучно. Это конечно удобно для разработчика, но с т.з. быстродействия все же лучше в коде указать список полей для выборки, нежели "пилить" таблицу.

Хотя это, вероятно, офтопик дла данного раздела, но на самом деле, в большинстве случаев, разницы никакой нету. Все равно читается вся запись из БД и оттуда вынимаются все данные (даже если в запросе перечислена всего одна колонка). Единственные два исключения - покрывающие индексы и clustered views (которые, по моему, в 2012 не поддерживаются). Если у тебя есть, индекс по custAccount+salesId, то запрос select salesId from table where custAccount='blah' будет обрабатываться только чтением из индекса, в то время как запрос select * from table where custAccount='blah', будет приводить к чтению из индекса и из самой таблицы (ну или кластерного индекса если он есть).

[mifi]

Цитата:

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

Хотя это, вероятно, офтопик дла данного раздела, но на самом деле, в большинстве случаев, разницы никакой нету. Все равно читается вся запись из БД и оттуда вынимаются все данные (даже если в запросе перечислена всего одна колонка). Единственные два исключения - покрывающие индексы и clustered views (которые, по моему, в 2012 не поддерживаются). Если у тебя есть, индекс по custAccount+salesId, то запрос select salesId from table where custAccount='blah' будет обрабатываться только чтением из индекса, в то время как запрос select * from table where custAccount='blah', будет приводить к чтению из индекса и из самой таблицы (ну или кластерного индекса если он есть).

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

[fed]

Цитата:

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

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

Угу - забыл перечислить. Кстати - гораздо более жизненный пример - таблица reqLog. У меня на проекте форма reqLog открывалась порядка 30 минут при примерно 60 записях.

[AndyD]

Цитата:

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

Хотя это, вероятно, офтопик дла данного раздела, но на самом деле, в большинстве случаев, разницы никакой нету. Все равно читается вся запись из БД и оттуда вынимаются все данные (даже если в запросе перечислена всего одна колонка). Единственные два исключения - покрывающие индексы и clustered views (которые, по моему, в 2012 не поддерживаются). Если у тебя есть, индекс по custAccount+salesId, то запрос select salesId from table where custAccount='blah' будет обрабатываться только чтением из индекса, в то время как запрос select * from table where custAccount='blah', будет приводить к чтению из индекса и из самой таблицы (ну или кластерного индекса если он есть).

Ну, чтение из файла - это же не весь цикл получения данных по запросу.
При большом размере записи будет за один раз меньше кол-во переданных на клиент данных
Простой запрос select * from InventTable на моих данные в два с половиной - три раза медленнее, чем select itemId from InventTable

[Alexius]

Цитата:

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

Простой запрос select * from InventTable на моих данные в два с половиной - три раза медленнее, чем select itemId from InventTable

Бесспорно, т.к. во втором случае серверу БД нет необходимо читать данные из всей таблицы с кучей полей, а достаточно воспользоваться одним из некластерных индексов содержащих ItemId (GroupItemIdx, TypeIdx, DimGroupItemIdx, и т.д.)

[AndyD]

Цитата:

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

Бесспорно, т.к. во втором случае серверу БД нет необходимо читать данные из всей таблицы с кучей полей, а достаточно воспользоваться одним из некластерных индексов содержащих ItemId (GroupItemIdx, TypeIdx, DimGroupItemIdx, и т.д.)

Не понятно, почему именно некластеным?
В обоих запросах используется как-раз таки кластерный ключ по ItemId, что эквивилентно пробегу по странцам с данными

[fed]

Цитата:

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

Не понятно, почему именно некластеным?
В обоих запросах используется как-раз таки кластерный ключ по ItemId, что эквивилентно пробегу по странцам с данными

Рискну предположить, что у вас в рознице слишком уж много полей в inventTable и при этом сама таблица прочно закэширована в памяти SQL Server. Поэтому начинают играть затраты на передачу данных по сети, поскольку затраты на чтение с диска минимизированы. Но все равно - в большинстве случаев, затратами на передачу данных между сервером и клиентом - можно пренебречь.

[Alexius]

2 AndyD
На сколько я понял, структура данных АХ 2012, описанная в Implementing_InventTrans_refactoring_for_Microsoft_Dynamics_AX_Applications_AX2012.pdf не соответствует действительности.

[Alexius]

Цитата:

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

Не понятно, почему именно некластеным?

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

Цитата:

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

В обоих запросах используется как-раз таки кластерный ключ по ItemId, что эквивилентно пробегу по странцам с данными

Т.е. план выполнения запросов на MS SQL одинаковый для обоих запросов ?

SELECT * FROM INVENTTABLE

SELECT ItemId FROM INVENTTABLE