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

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

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


Пример из жизни.
Было две таблицы - TableA и TableB - на них имелись суррогатные ключи. Между ними должна была быть связь многие ко многим. Понятное дело что нужно всего лишь организовать таблицу с двумя полями TableA_ID, TableB_ID, И комбинация этих полей - уникальна. И на эту таблицу нужно построить 2 индекса по (TableA_ID, TableB_ID) и по (TableB_ID, TableA_ID).
Но почему-то один "проектировщик" добавляет еще и третье поле - которое Identity, и тоже уникально для каждой записи. Зачем?... Понятно, что этот индекс и это поле никогда не будут использоваться. Вот и старайтесь, чтобы у вас такого тупизма не было.

Каждое поле, каждый индекс должен где-то использоваться. Чем меньше индексов - тем больше перфоменс при добавлениях/удалениях/исправлениях. Анализируйте структуру таблиц. Смотрите какие запросы какие индексы используют. Это долго и трудно.