axdaily: Surrogate keys in AX 2012

[Blog bot]

Источник: http://axdaily.blogspot.com/2011/05/...n-ax-2012.html
==============

Data modeling enhancements were prioritized really high in AX 2012. I already mentioned one earlier – table inheritance, but there are a lot of other important features about data modeling.

One such feature is the support of surrogate keys. Surrogate keys recommended themselves as a very good solution for complex databases because of their beneficial properties, like immutability, robustness to redesign and performance. 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.

Actually, previous versions of AX already have surrogates – RecIds. And it was possible to introduce surrogate key just by setting CreateRecIdIndex table property to Yes. But there is a problem with the inconvenience of working with surrogates in the UI. Imagine InventTable using surrogate key and all other tables that have relations to InventTable using its surrogate key as a foreign key. 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.

Let me show an example of how it works:
UnitOfMeasure table uses surrogate key as a primary key. However, the user-friendly identifier of the UnitOfMeasure table records is the UnitOfMeasureSymbol field. This field is a part of the SymbolIdx index, which is specified as a replacement key on the UnitOfMeasure table.


This setup basically means that surrogate key values (RecIds) of the UnitOfMeasure table records will be automatically substituted in the UI with the replacement key values (UnitOfMeasureSymbols).
UnitOfMeasureConversion table has a relation to the UnitOfMeasue table through the surrogate key.


As you can see, on the UnitOfMeasureConversion form there are only UnitOfMeasureConversion datasources. And you can notice new ReferenceGroup control which is bound to the FromUnitOfMeasure field (which contains surrogate values).


And in the UI it will look just like UnitOfMeasureSymbol field is shown instead. And it can also be modified and that will be handled automatically, without a single line of code.


Actually ReferenceGroup control has much more interesting capabilities and thus deserves a separate post.


Источник: http://axdaily.blogspot.com/2011/05/...n-ax-2012.html

[mazzy]

вот ведь. сделали таки.
интересно что стало с переименованием ключевых полей

Цитата:

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

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.

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

Цитата:

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

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.

мдя... радикально.
все придется переписывать нафиг.

а я легко могу предложить good reason не делать суррогатных ключей - foreign key таблица содержит много записей.
типичный случай - custTrans и custSettlement.

CustSettlement содержит две recId-ссылки на CustTrans, которые действительно должны быть recId-ссылками и которые надо отображать пользователям в человеческом виде. При большом размере custTrans (с точки зрения производительности) лучше не делать join для разименования, а все-таки оставить денормализацию в CustSettlement как это сделано сейчас. С четким пониманием, что денормализация сильно затрудняет поддержку целостности базы данных.

Цитата:

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

UnitOfMeasureConversion table has a relation to the UnitOfMeasue table through the surrogate key.

Почему relation на таблице то?
Почему не в типе?

[S.Kuskov]

Цитата:

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

Почему relation на таблице то?
Почему не в типе?

Так а на каком типе то этот relation может быть в таком случае? Связь то по RecId

Цитата:

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

а я легко могу предложить good reason не делать суррогатных ключей - foreign key таблица содержит много записей.
типичный случай - custTrans и custSettlement.

На сколько я понял, custSettlement как раз уже сейчас исполнена в стиле сурогатных ключей (читай имеет foreign key с типом RecId). Правда этот пример не очень коректен, так как в custTrans поле RecId - это и есть первичный ключ. Естественный первичный ключ для custTrans был бы уж очень составным, если вообще был бы

[MikeR]

Насколько я понял mazzy, связь через типы просто убрали, как рудимент, и теперь придется связи между сущностями только на таблице и определять.

[mazzy]

Цитата:

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

Так а на каком типе то этот relation может быть в таком случае? Связь то по RecId

хм... надо подумать.

Цитата:

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

На сколько я понял, custSettlement как раз уже сейчас исполнена в стиле сурогатных ключей (читай имеет foreign key с типом RecId). Правда этот пример не очень коректен, так как в custTrans поле RecId - это и есть первичный ключ. Естественный первичный ключ для custTrans был бы уж очень составным, если вообще был бы

да. но... в общем, надо подумать.

Цитата:

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

Насколько я понял mazzy, связь через типы просто убрали, как рудимент, и теперь придется связи между сущностями только на таблице и определять.

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

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

[Logger]

Цитата:

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

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

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

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

[S.Kuskov]

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

[gigz]

Цитата:

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

Ну, join будет, конечно. Имеется в виду только то, что его не нужно делать вручную.

Цитата:

Почему relation на таблице то?
Почему не в типе?

MikeR прав - отношений на EDT больше нет

Цитата:

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

Да, так часто делают (тоже вроде как best practice). Для того, чтобы метки и лукапы цеплять на reference group.

[mazzy]

Цитата:

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

Ну, join будет, конечно. Имеется в виду только то, что его не нужно делать вручную.

Некоторые системы отечественного производства... (назовем их для краткости СОП )
которые изначально содержали разыменование...
на ранних стадиях страдали ошибками типа "в запросе не может участвовать более 256 таблиц"...

теперь эти СОП принудительно разбивают запрос на несколько

[mazzy]

кроме того, сразу возникает вопрос о поиске по суррогатному ключу
или по его разыменованию.

[S.Kuskov]

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

[S.Kuskov]

Мне больше интересно, а что будет с существующими псевдосурогатными ключами. Например JournalId, BOMId, RouteOprId. Их признают псевдоестественными и надстроют над ними сурогатные ключи по RecId или вовсе уберут заменив каким-нибудь "номером первичного документа" и "уникальным наименованием"?

Цитата:

It is the recommendation for AX 2012 to use surrogate keys for all new tables

Или это относится только к новым таблицам. А архитектура имеющихся переписана не будет?

[gigz]

Цитата:

Некоторые системы отечественного производства... (назовем их для краткости СОП )
которые изначально содержали разыменование...
на ранних стадиях страдали ошибками типа "в запросе не может участвовать более 256 таблиц"...

теперь эти СОП принудительно разбивают запрос на несколько

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

Цитата:

Мне больше интересно, а что будет с существующими псевдосурогатными ключами. Например JournalId, BOMId, RouteOprId. Их признают псевдоестественными и надстроют над ними сурогатные ключи по RecId или вовсе уберут заменив каким-нибудь "номером первичного документа" и "уникальным наименованием"?


Цитата:
It is the recommendation for AX 2012 to use surrogate keys for all new tables

Или это относится только к новым таблицам. А архитектура имеющихся переписана не будет?

Псевдосуррогатные ключи в теории будут убираться.
Но на данном этапе этот best practice действительно касается в основном новых таблиц. Старые будут переходить на суррогатные ключи очень постепенно.

Цитата:

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

Это решается паттерном unit of work. В АХ 2012 он поддерживается достаточно хорошо. Напишу следующий пост про него.

[S.Kuskov]

Цитата:

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

Это решается паттерном unit of work. В АХ 2012 он поддерживается достаточно хорошо. Напишу следующий пост про него.

Спасибо за пост axdaily: Unit of Work

[EVGL]

Коллега уже ругается: отлаживать стало несравнимо труднее. Имеем в дебаггере табличку, а в ней - только RecId. Те, кто имели дело с Global Address Book поймут - теперь вся система такая. Импорт данных консультантами тоже превратится в занимательное приключение.