Цитата:
Некоторые системы отечественного производства... (назовем их для краткости СОП
)
которые изначально содержали разыменование...
на ранних стадиях страдали ошибками типа "в запросе не может участвовать более 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 он поддерживается достаточно хорошо. Напишу следующий пост про него.