axdaily: Surrogate keys in AX 2012

[Logger]

Цитата:

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

А что, сейчас лиший join не делается?

Судя по описанию не делается.
Т.е. в табличке UnitOfMeasureConversion содержится как поле с суррогатным ключом (refRecId) так и поле с ItemID.
Поля работают в паре.
Для отображения юзеру используется ItemId. Для поиска джоинов, основного индексирования используется суррогат refrecId. При этом ядро само отображает вместо refrecId - соответствующий ему ItemID (ради это группа контролов заводится) но без подзапросов и джоинов к родительской табличке. (Я при этом не понял если задать из кода refrecID, то ItemId ядро автоматом подтянет или нет ? Если автоматом. то вообще красавцы )

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

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

[S.Kuskov]

Цитата:

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

Судя по описанию не делается

А можно цитату?

Я что-то очень сомневаюсь в том что происходит повсеместное дублирование данных ради исключения джойна.

Цитата:

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

Я при этом не понял если задать из кода refrecID, то ItemId ядро автоматом подтянет или нет ? Если автоматом. то вообще красавцы

А как вы себе это представляете для случая, когда естественный ключ будет составным (это в примере индекс Symbolidx содержит одно поле, но на сколько я понимаю, ReplacementKey может быть и составным)?

[mazzy]

Цитата:

Сообщение от S.Kuskov

Я что-то очень сомневаюсь в том что происходит повсеместное дублирование данных ради исключения джойна.

я тоже.
тем более, что возможно разыменование в несколько полей
см. mfp: Microsoft Dynamics AX Technical Conference Recordings

[S.Kuskov]

Цитата:

Then on any form where ItemId should be displayed (let’s say on the SalesTable) an extra join to InventTable will be needed to fetch the ItemId. And what if user can change the item? Then even more custom logic is needed to resolve the entered ItemId to the corresponding surrogate key value and write it to the SalesLine.

This inconvenience actually was a showstopper. But not anymore. AX 2012 got kernel support for surrogate key substitution. And not only in forms, but in Axd document services and even in the debugger.

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

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

[mazzy]

Цитата:

Сообщение от S.Kuskov

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

это-то и беспокоит.

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

это значит "лишние join" будут встречаться очень часто.
а раз заложено при проектировании, то и избавиться от лишних Join будет чертовски сложно.

================
достаточно посмотреть в одну из уже существующих СОП (систем отечественного производства)

[mazzy]

Цитата:

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

это значит "лишние join" будут встречаться очень часто.
а раз заложено при проектировании, то и избавиться от лишних Join будет чертовски сложно.

тем более, что

Цитата:

Сообщение от Blog bot

And now this best practice is coming to AX. It is the recommendation for AX 2012 to use surrogate keys for all new tables, unless there is a good reason not to do so.

[Logger]

Цитата:

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

это-то и беспокоит.
это значит "лишние join" будут встречаться очень часто.
а раз заложено при проектировании, то и избавиться от лишних Join будет чертовски сложно.

А нужно ли от них избавляться ?
Я чо-то сомневаюсь что там внесли серьезные изменения без тестирования на больших объемах данных. Может мы просто привыкли по старинке работать и не видим плюсов от нового подхода.

[Logger]

Цитата:

Сообщение от S.Kuskov

А можно цитату?

Я что-то очень сомневаюсь в том что происходит повсеместное дублирование данных ради исключения джойна.
...
А как вы себе это представляете для случая, когда естественный ключ будет составным (это в примере индекс Symbolidx содержит одно поле, но на сколько я понимаю, ReplacementKey может быть и составным)?

Похоже я поспешил и этого не происходит. Обшибся