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

[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. Вы правы, конечно, это так.