Используете ли вы суррогатные ключи?

[sukhanchik]

Суррогатные ключи и есть RecId в понятии АХ - т.о. их специально создавать не надо. Конечно можно и свой создать, но это уже будет совсем излишняя работа (на мой взгляд).

Нужен ли метод findRecId? Я считаю, что нужен. Я вообще еще с ранних версий всегда придерживался идеологии, что лишний метод, который представляет собой дополнительное API - лишним не будет, даже если он нигде не используется. Это слегка противоречило взглядам сотрудников из MS, но ... это не меняло моего подхода.

На практике ключевыми критериями необходимости суррогатного ключа для меня всегда являлось:
1. Удобство переноса данных (если данные необходимо переносить - например, это те или иные настройки) - то суррогатные ключи идут лесом - это сильное усложнение поддержки. Библия библией, а простота поддержки важнее библии (это лично мое мнение).

2. Необходимость иметь некий идентификатор для пользователя, например, код заказа на продажу, код ваучера и т.д. В этом случае суррогатные ключи непрезентабельны и опять лишний раз усложняют работу с данными. К примеру, InventDimId вполне мог себе быть суррогатным ключом, т.к. он не является для пользователя каким-либо идентификатором.

3. Заведомо известная ситуация, при которой ключом является другое поле (не RecId). Например, импортируются данные из другой программы вместе с идентификатором записи из другой программы. В этом случае (если заведомо точно известно, что ошибочных ситуаций быть не может) ключом можно назначить другое поле. Это удобно, если по этому полю (что скорее всего) будет выполняться поиск.

Ну а в остальных случаях ... в общем -то можно обойтись и суррогатными ключами. Хотя лично мне ближе в душе естественные ключи и суррогатный ключ я большей частью делаю только в том случае, когда использование естественного ключа неудобно / невозможно (тот же InventDimId по сути - суррогатный ключ)