axdaily: Surrogate keys in AX 2012

[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 будет чертовски сложно.

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