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

[Alexius]

Цитата:

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

Не согласен. На мой обывательский взгляд, чем меньше таблица - тем больше из нее поместится в кэш.

Для MS SQL не совсем так. Сервер стремится кэшировать наиболее часто используемые данные и далеко не обязательно это должна быть целиком вся таблица. При построении структуры БД желательно помочь ему в этом, для этого мне кажется лучше было бы:
1. Объединить даты в одно поле
2. Объединить статусы прихода и расхода и выстроить их в порядке возрастания
3. Ввести уникальный ключ для InventTrans (пeсть и в связке с InventTransId)
4. Данные по накладным (отгрузочные, отборочные, финансовые) выделить в отдельную таблицу и при обработке последующей накладной добавлять строно запись по предыдущей.

Цитата:

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

, а Кроме того, в большинстве случаев в запросах к InventTrans поля InventRef и прочие не используются. В этом плане решение перебросить их в другую таблицу кажется логичным.

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

[S.Kuskov]

Цитата:

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

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

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

[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, к примеру

[AndyD]

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

[fed]

Цитата:

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

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

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

[AndyD]

Цитата:

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

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

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

[mifi]

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

[fed]

Цитата:

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

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

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

[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, что намного удобнее, имхо.

[sukhanchik]

Но от этого же отказались в 2012 - или я неправильно понял - и текст был не об этом?

Цитата:

Visio Export for reporting relationships, locations, and organizational structure views
In Microsoft Dynamics AX 2009, you can export the reporting relationships view, locations view, and organizational structure view to Visio.
Reason for deprecation: Architectural changes and a new control were added to all three of the views. The new control enables more nodes to be displayed in the hierarchical structure. You can also create and modify nodes directly from the new control. The architectural changes would have required extensive changes to the Visio Export feature.
Replaced by another feature: No. The Visio Export feature is no longer available, and there is no replacement feature.

[kashperuk]

Это касается только перечисленный элементов - org.structure related.
(Были такие формочки как Locations View, к примеру - причем красивая формочка была).

Это не имеет никакого отношения к модели данных или классов - это все осталось.

[sukhanchik]

Спасибо, понял. Не было ключевого словосочетания Reverse Engineering
И к слову сказать - MorphXplorer (см http://axapta.mazzy.ru/lib/steps/step09.html) умел и с иерархией классов работать