Зачем указывать replacementKey, если сразу можно primary заменить на нужный alternateKey?

[kitty]

Если в уникальном ключе одно поле и AlternateKey = true, то его можно указать как PrimaryKey. Вопрос - почему так не делается в стандарте?
Например, в стандартной таблице UnitOfMeasure, можно было бы сразу указать PrimaryKey = SymbolIdx. Но зачем-то Primary оставлен суррогатным, а replacementKey =SymbolIdx.
(лукапы все норм работают ? и unitOfWork тоже, если заменить primary на один из alternate)

[S.Kuskov]

Работать то оно будет, но с той же ли производительностью? Суррогатный ключ может иметь преимущество не только над составным но и над ключом из одного поля, если оно к примеру строковое, а не целочисленное

[kitty]

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

[S.Kuskov]

А вторичные ключи в сотне подчинённых таблиц? Будут они строковыми либо целочисленными, есть разница?
По поводу строк ещё сразу всплывает проблема с поддержкой мультиязычности.
В конце концов архитектурно красивая абстракция получается. Не смешиваются ссылка на данные и сами данные.

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

Я так понимаю, речь идет об Ax2012. В "теории" альтернативный и первичные ключи имеют разную область применения.

Первичный ключ - это ключ, используемый для связки PK-FK. Т.е. ключ, обеспечивающий ссылочную целостность данных. Внутри самой базы данных. Как правило, на формах не отображается и пользователь его не видит.

Альтернативный ключ - это ключ, используемый для идентификации записи пользователем. Т.е. для поиска в различных формах и lookup.

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

Альтернативный ключ, как правило, значительно больше по размеру (в байтах), чем первичный ключ. Поскольку для связи с другими таблицами его значение надо записать как FK в этих самых "других" таблицах, то размер имеет существенное значение.

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

Да, разумеется, иногда размер альтернативного ключа может быть меньше размера первичного ключа. Но обычно это исключения. И в таких случаях следует все оставить "по стандарту". "Пусть безобразно, зато единообразно" (с)

Но! Это все "теория". На практике, по крайней мере в Ax2009, PrimaryIndex использовался именно как альтернативный. В Ax2009 связка PK-FK на уровне базы данных не поддерживалась. Не знаю, изменилось ли что-нибудь в Ax2012. На уровне базы данных Primary Key создается?

[ice]

Суррогатный ключ это индекс по RecId. если на форму выводится ссылка на суррогатный ключ(RecId), если он первичный, то на форме отображается поле входящее в ReplacementKey. и вводить значение в него можно именно из значений ReplacementKey, такая же связь работает в Excel AddIns
ПС в этом кроется засада: ядро системы формирует запрос к таблице на которую дана ссылка для отображения поля из ReplacementKey, если таких ссылок много то возникают проблемы с производительностью на форме

[kitty]

Цитата:

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

А вторичные ключи в сотне подчинённых таблиц? .

Я согласна со всеми пунктами, и концептуально правильно указывать суррогат как pk, раз уж он fk в других таблицах.
У нас тут немного кавардак, и где как указаны индексы, вот думаю, нужно ли все менять или лучше оставить как есть, раз уже работает.
Поэтому возникают вопросы:

Чего я не понимаю:
1) Что перестанет работать, если я просто укажу SymbolIdx в качестве первичного?
2) Если связи не по суррогатному ключу, а по другому полю, то можно ли оставлять превичным суррогат?
3) Есть ли случаи, когда все связи построены по суррогатному ключу, но нужно указывать другой уникальный ключ в качестве первичного?

Я пока поэкспериментировала и кроме как логического смысла, в поведении системы разницы не вижу в зависимости от того, суррогат первиченным указан или другой уник индекс.

[gl00mie]

Цитата:

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

1) Что перестанет работать, если я просто укажу SymbolIdx в качестве первичного?

Как минимум на формах, в отладчике и тому подобных местах перестанет работать автоподстановка значения альтернативного ключа (UnitId) вместо значения UnitOfMeasure.RecId, а на ЕИ по RecId ссылается очень-очень много таблиц.

Цитата:

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

2) Если связи не по суррогатному ключу, а по другому полю, то можно ли оставлять первичным суррогат?

Почему нет? Особенно если речь о стандартной таблице. А уж как вы в кастомизациях ссылаетесь на ее записи - это дело ваше.

Цитата:

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

3) Есть ли случаи, когда все связи построены по суррогатному ключу, но нужно указывать другой уникальный ключ в качестве первичного?

Кому нужно? Это чисто гипотетический вопрос?

Цитата:

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

Я пока поэкспериментировала и кроме как логического смысла, в поведении системы разницы не вижу в зависимости от того, суррогат первиченным указан или другой уник индекс.

Разница есть как минимум в работе ReferenceGroup на формах: эти контролы, насколько я знаю, "не умеют" работать по FK, отличным от суррогатных ключей.

[kitty]

Цитата:

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

Как минимум на формах, в отладчике и тому подобных местах перестанет работать автоподстановка значения альтернативного ключа (UnitId) вместо значения UnitOfMeasure.RecId, а на ЕИ по RecId ссылается очень-очень много таблиц.

Все работает.
Специально сейчас на unitOfMeasure поставила PrimaryKey = SymbolIdx, и проверила - лукапы в ссылающихся таблицах норм работают, тк связь как была по recId, так она и осталась и используется.

Тут еще узанала, что, если оставить primaryKey суррогатным и если воспользоваться переименованием первичного ключа в контекстном меню, то будет для переименования выдаваться recId, а не уник поле, кот имеет смысл переименовывать для пользователя. Попробовала на бедном unitOfMeasure - действительно, если primary - recId, то для переимования предлагается recid, если заменить на symbolIdx, то можно переименовать саму единицу измерения.

Это так и задумано??? Как же тогда, действительно, переименовывать?

[S.Kuskov]

Цитата:

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

Это так и задумано??? Как же тогда, действительно, переименовывать?

А что вам не нравится? Если ключом является RecId, то переименование ключа - это замена одного значения RecId на другое. По моему, все логично. Понадобиться такое может разве что при объединении строк (merge).

Что значит действительно переименовать? Для того чтобы изменить не ключ а сами данные никаких хитрых инструментов не нужно.

[kitty]

Спасибо, S.Kuskov. Вы правы, конечно, это так.