Surrogate foreign keys в InventDim

[lvan]

Что думаете, есть в этом смысл или нет?
Новую аналитику думаю добавить так.

[S.Kuskov]

Технически реализуемо. Но только ради чего? Расскажите.
У вас новая аналитика является составной? Тогда такой шаг может быть оправдан. Только нужно понимать что это будет пусть сложная но единая аналитика. Т.е. в настройках групп аналитик нельзя будет назначить разные свойства на отдельные части этой составной аналитики.

Какая версия системы? В AX2009 я бы всё таки использовал "псевдоестественный" ключ - автоматически генерируемый номерной серией. В AX2012 уже можно, пользуясь встроенной поддержкой разименовывания, делать связь по RecId.

[Владимир Максимов]

Если под термином "суррогатный ключ" подразумевается некий внтуренний идентификатор записи, который не видит пользователь (например, RefRecId), то до версии Ax2012 - это нарушение BestPrictices

Если же этот самый "суррогатный ключ" будет видеть пользователь, то это ничем не отличается от того, что есть сейчас. Ведь и так, например, "Склад" в складской аналитике - это foreign Keys на запись справочника складов.

[S.Kuskov]

Цитата:

Сообщение от Владимир Максимов

Если же этот самый "суррогатный ключ" будет видеть пользователь, то это ничем не отличается от того, что есть сейчас. Ведь и так, например, "Склад" в складской аналитике - это foreign Keys на запись справочника складов.

"Склад" в складской аналитике - это foreign Keys на запись справочника складов - Согласен, но это никак не делает его суррогатным. Идентификатор склада вполне естественный код.

[Владимир Максимов]

Термины "суррогатный" и "естесственный" ключи - не есть термины теории реляционных баз данных. Это значит, что каждый вкладывает в это понятие некий свой собственный, "сокровенный" смысл. Лично я для себя даю такое определение

Суррогатный ключ - это идентификатор записи, сформированный внутри приложения и никак, никоим образом, не (!) зависящий от "внешнего мира".

Естесственный ключ - это идентификатор записи, пришедший из вне приложения и зависящий (!) от "внешнего мира". Т.е. если значение ключа поменялось во вне приложения, то его надо будет изменить и внутри приложения.

Т.е. для меня "суррогатный" отличается от "естесственного" только фактом зависимости его значения от "внешнего мира". И на этом все. Никакие другие характеристики не имеют никакого отношения к его "суррогатности" или "естественности". В том числе и способ формирования.

Какая разница как именно он был сформирован? Из номерной серии или введен руками. Например, ИНН (номер паспорта, ГТД, код города) - это номерная серия или руками вводился? А если по умолчанию код записи справочника формируется из номерной серрии, но Вы можете его изменить в момент создания записи - код перестает быть суррогатным? Т.е. часть записей таблицы имеет суррогатный ключ, а часть естесственный?

[kashperuk]

Я бы не стал этого делать.
Я не пробовал, но скорее всего придется дописывать кастомный код везде, для обработки суррогатных ключей, плюс нет гарантии что оно отобразится нормально (reference group control) на формах. Должно, но, опять же, я не пробовал.

Тем более что ничего особо "плохого" в текущем подходе с использованием строковых значений нет.

[kashperuk]

В АХ 2012 термин суррогатный ключ - это ключ основанный на RecId
Естественный ключ - строковой ключ, который может быть прочитан (и понят) человеком.

Номерные серии я бы отнес к суррогатным, но я не помню, чтобы это кто-либо делал в процессе разработки АХ 2012

[lvan]

AX2012 конечно, Surrogate key - это RecId. Для новых таблиц в AX2012 он по умолчанию является Primary key. Но в AX2012 сделали так, что его значение может разыменовываться в Natural Key и вместо int64 отображается именно значение Natural Key

[lvan]

Цитата:

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

Я бы не стал этого делать.
Я не пробовал, но скорее всего придется дописывать кастомный код везде, для обработки суррогатных ключей, плюс нет гарантии что оно отобразится нормально (reference group control) на формах. Должно, но, опять же, я не пробовал.

Тем более что ничего особо "плохого" в текущем подходе с использованием строковых значений нет.

Ну типа бест практис же, и таблица довольно большая, так что будет экономия на месте и скорости.
Дописывать наверное нужно будет код, который к контролам аналитики напрямую обращался, чтобы была поддержка ReferenceGroup.
Больше на вскидку ничего не могу припомнить, может я что-то упускаю, что реально бы затруднило?

[Владимир Максимов]

Я не в курсе, в Ax2012 остался функционал по динамической настройке того, какие именно поля из складской аналитики отображать в строках документов и отчетах? Имею в виду, например, в строках заказа в Ax2009 кнопка "Запасы" \ Отображать аналитики. Классы-наследники от InventDimCtrl. Или именно это и реализовано через ReferenceGroup?

Ссылка через суррогатный ключ ведь будет отображать собственно значение суррогатного ключа. Или там более хитрый функционал?

[lev]

Цитата:

Сообщение от Владимир Максимов

например, в строках заказа в Ax2009 кнопка "Запасы" \ Отображать аналитики.

это в AX2012 осталось.

[lvan]

Владимир Максимов, вы видимо не в курсе изменений в AX2012
Рекомендую ознакомиться, это обсуждалось полтора года назад axdaily: Surrogate keys in AX 2012

[Владимир Максимов]

Цитата:

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

Владимир Максимов, вы видимо не в курсе изменений в AX2012
Рекомендую ознакомиться, это обсуждалось полтора года назад axdaily: Surrogate keys in AX 2012

Так я и спрашиваю ЧТО будет отображаться в формах и отчетах если в складской аналитике заменить ссылки на RecId? Каким образом будет работать весь этот функционал динамической подстановки/удаления полей складской аналитики на формы и отчеты? Придется переписать его целиком чтобы подставлять поля из других таблиц (дисплейные методы)? А фильтрация по полям складской аналитики останется? Или в каждой форме кроме собственно InvendDim в качестве DataSource придется подтягивать еще справочники аналитик?

==================

Вот теперь дошло. Т.е. кроме замены ссылок на RecId придется перелопатить кучу форм и отчетов и заменить поля типа String на поля типа ReferenceGroup. Мда... Работенка еще та предстоит...

Только вот по прежнему не понятно, фильтрация по полям типа ReferenceGroup возможна или они как дисплейные методы - только отображают, но не дают фильтровать?

[lvan]

В том то и дело, что ReferenceGroup автоматически создается (в случае автоматической группы полей - а аналитика в подавляющем большинстве случаев именно через группу полей отображается)
Т.е. вручную вроде ничего не надо менять. По крайней мере с формами так, про отчеты не знаю

[trud]

Цитата:

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

Т.е. вручную вроде ничего не надо менять. По крайней мере с формами так, про отчеты не знаю

Готовьтесь что отчеты придется все переписывать(добавлять туда новую аналитику). никаких групп полей как в 2009 теперь нет. по крайней мере так было в 2012CU2. не знаю изменили ли они движок вывода аналитик в R2