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

[AndyD]

Цитата:

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

1. Почему название поля InventTransOrigin с названием таблицы ? Логичнее кажется добавить для единообразия суффикс Id

Поле InventTransOrigin - это ссылка на поле recId в таблице InventTransOrigin. Возможно, поэтому и не стали добавлять суффикс

Цитата:

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

2. Есть ли таблица InventTransOrigin и по каким полям она связывается с InventTrans и InventTransOriginSalesLine (и т.д.) или ее поля перекочевали в InventTransOriginSalesLine (и т.д.), что согласуется с примером запроса, но не структурой БД ?

Таблицу InventTransOrigin следует использовать, если идти от InventTrans - по ней можно узнать, какой модуль сгенерировал проводку и дальше провалиться в модулные проводки через inventTransId

Цитата:

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

3. Поле InventTrans.InventTransOrigin на сколько я понял из запроса сделано уникально для идентификации записи InventTrans?

Там четыре поля
DATAAREAID, INVENTTRANSORIGIN, INVENTDIMID, RECID
Индекс - кластерный

Цитата:

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

4. Зачем поле OriginatingTable в таблицах InventTransOriginSalesLine (и т.д.) ?

Не нашел такое
Если имеет в виду InventTransOrigin<OriginatingTable>::findInventTransOriginId(…), то InventTransOrigin<OriginatingTable> - это название таблицы, InventTransOriginSalesLine, к примеру

[Alexius]

Цитата:

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

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

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

[S.Kuskov]

Цитата:

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

А как же банальная формочка просмотра проводок, если в нее попадает несколько сотен записей, то скорость работы с объединенными табличками скорее всего будет близка к скорости работы с одной, но если туда будут попадать тысячи записей, то накладные расходы сервера на объединение будут ощутимыми.

Скорее всего сделают связь с модульными таблицами в режиме Delayed, а не InnerJoin.

[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

[AndyD]

Да, розница
Но этот запрос я делал на тестовом сервере, где людей вообще нет.
Да и затраты здесь идут не от прокачки бо'льших объемов по сети, а от используемых серверных курсоров и операции фетча, вызовы которой дают значительный оверхед на операции

[fed]

Цитата:

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

Да, розница
Но этот запрос я делал на тестовом сервере, где людей вообще нет.
Да и затраты здесь идут не от прокачки бо'льших объемов по сети, а от используемых серверных курсоров и операции фетча, вызовы которой дают значительный оверхед на операции

Может вы туда еще и container-field добавили ? Просто, насколько я помню, обычно в запрсое используются легкие курсоры (это fast forward кажется), но если в таблице есть BLOB-поля,то легкие курсоры автоматически апгрейдятся SQL-server до нелегких. (Не помню точно каких).

[AndyD]

Цитата:

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

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

SELECT * FROM INVENTTABLE

SELECT ItemId FROM INVENTTABLE

Вы правы, индексы в данном случае разные.

Но переделка запроса на поле, не участвующее ни в одном индексе картину не поменяло - скорость различается на те же 2,5-3 раза

[mifi]

В чем я вижу преимущество данной модели - добавление полей для кастомизации хорошо ложиться на данную модель. Очень часто на проектах встречается, что в InventTrans добавлено с десяток полей, причем в основном не типа CostAmount, а как раз очень сильно зависящих от источника. Даже не говоря о производительности, будет намного более понятно и логично, если их разложить по InvenTransOriginам. Хотя, IMHO, количество Originов действильно немного большее, чем достаточное

[Alexius]

Цитата:

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

Но переделка запроса на поле, не участвующее ни в одном индексе картину не поменяло - скорость различается на те же 2,5-3 раза

Занятно, я ожидал уменьшения разницы. Видимо действительно в этом примере так велики затраты на формирования набора записей со всеми полями и возвращение его клиенту (АОСу). В любом случае запросы с избыточным числом полей ЗЛО

[fed]

Цитата:

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

В чем я вижу преимущество данной модели - добавление полей для кастомизации хорошо ложиться на данную модель. Очень часто на проектах встречается, что в InventTrans добавлено с десяток полей, причем в основном не типа CostAmount, а как раз очень сильно зависящих от источника. Даже не говоря о производительности, будет намного более понятно и логично, если их разложить по InvenTransOriginам. Хотя, IMHO, количество Originов действильно немного большее, чем достаточное

Я предполагал что они выделят таблички типа inventTransProd (с данными о маршруте и спецификации), inventTransCustVend (с данными о закупках/продажах, может еще налогах), inventTransJournal (для складских журналов) и inventTransOther (помойка - для всего остального). В общем - ничего кроме 'over-normalization', сказать не могу...

[AndyD]

Цитата:

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

Может вы туда еще и container-field добавили ? Просто, насколько я помню, обычно в запрсое используются легкие курсоры (это fast forward кажется), но если в таблице есть BLOB-поля,то легкие курсоры автоматически апгрейдятся SQL-server до нелегких. (Не помню точно каких).

Блоб-полей нет
В обоих случаях тип курсора Fast forward-only cursor

[Ievgenii]

День добрый,

Цитата:

Назначение всех неслужебных таблиц должно быть объяснимо в терминах специалистов предметной области. Типа: CustInvoiceJour - шапки накладных, CustInvoiceTrans - строки накладных, CustTrans - субконто проводок по поставщику, CustSettlement - данные о сопоставлениях (закрытии друг на друга) платежей и оплат.
Боюсь что "эта ваша" схема разложения складских проводок не в состоянии преодолеть этот простой критерий

Согласен - и правило имеет смысл только для сущностей (не для отношений) и для концептуальных и логических схем (которых вы есстно не видели пока), но не для физических! К сожалению в аксапте АОТ не моделирует даже логические сущности, по-этому в некоторых случиях физическая модель может отличаться (опят таки ради производительности как правило или за ограничений аксапты).

Цитата:

1. Почему название поля InventTransOrigin с названием таблицы ? Логичнее кажется добавить для единообразия суффикс Id

Для Ах2012 логичнее как раз без ID чтобы было ближе к логической модели

Цитата:

5. Что хранит поле InventTransOrigin.ItemInventDim ?

Item inventory dimensions . На самом деле itemId + ItemInventDim по определению равны сслылке на Product ( посмотрите на Product item data managament). Незнаю как это на русский переведут - товар или продукт наверно !?

[Ivanhoe]

Цитата:

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

На самом деле itemId + ItemInventDim по определению равны сслылке на Product ( посмотрите на Product item data managament). Незнаю как это на русский переведут - товар или продукт наверно !?

SKU? По-русски, наверное, ближайшее - Артикул.

[Ievgenii]

Цитата:

SKU? По-русски, наверное, ближайшее - Артикул.

Очень надеюсь что наша локализация найдет что то достойное - только не Stock keeping unit или то что под этим у нас понимается.

В Dynamics Ax 2012 такие сущности как SKU и/или Handling Units пока не реализованы (ИМО), но рано или поздно появятся и это вообще отдельная история.

Надеюсь терминологию не попутают

[Evgeniy2020]

как я понял все эти рефакторинги inventtrans и ledgertrans в AX 2012, а также табличное наследование и переделка relations для поддержки улучшенного моделирования. Судя пр тренду они хотят улучшить моделирование процессов и их отражение.

поэтому весь этот рефакторинг затеяли ради моделей, и лучшего проецирования моделей на физические сущности.

я так понимаю дальше появится наверно какой то инструмент Modeller (возможно UML modeller с генератором классов и таблиц на основе моделей)
возможно в следующей версии, с которым можно будет подбирать и строить лучшие модели а все физические сущности и связки будет делать modeller.
(то есть таблицы, иерархии, отношения)

явное прослеживается Единность модели базовый класс и наследники Базовая таблица и таблицы спутников наследников.

[sukhanchik]

Эх... и никто не вспоминает из 3.0 MorphX Explorer (или как он там назывался) - который умел рисовать все вот эти модельки. Да, он был конечно бедный... но был.

[kashperuk]

Цитата:

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

Эх... и никто не вспоминает из 3.0 MorphX Explorer (или как он там назывался) - который умел рисовать все вот эти модельки. Да, он был конечно бедный... но был.

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