Таблица с встроенным кластеризованным идентификатором и основным ключом NVarChar - к какому из них я присоединяюсь?

Question

Моя структура таблицы выглядит следующим образом:

USER:

UserId int - clustered index & identity 
UserName nvarchar - PK 
Name nvarchar 
Location nvarchar 

ТИПА ПОТРЕБИТЕЛЯ РЕГИСТРИРУЙТЕСЬ

UserName nvarchar - PK 
UserTypeId int - PK 

USER TYPE

UserTypeId int - PK 
Name nvarchar 

Первоначально мой User таблица не имеет UserId и я использовал UserName в качестве первичного ключа, а также идентичности и кластерных колонков, но это причиняло мне проблемы фрагментации, поэтому я добавил UserId и установить его на кластерный идентификатор индекса.

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

Я пробовал искать в Google ответ на этот вопрос, но я не могу придумать ничего подходящего.

Answer 1

Использование Int в качестве первичного ключа и выполнение всех объединений на основе этих столбцов будет быстрее, чем использование UserName, особенно, поскольку у вас есть кластерный индекс в этом столбце.

Возможно, вы должны изменить все свои соединения, чтобы использовать UserId и сделать этот столбец первичным ключом. Вы можете поместить уникальное ограничение в поле UserName, чтобы убедиться, что столбец остается уникальным.

Answer 2

Включение в UserId может сделать некоторые запросы более эффективными, но имейте в виду, что также могут быть затраты, связанные с ссылкой на UserId вместо UserName. Возможно, вам понадобится выполнить соединения, в которых вам не приходилось раньше, потому что имя пользователя теперь находится только в таблице User. Также вам, вероятно, понадобится дополнительный код приложения и уровня данных для обработки сопоставления и перевода между UserNames и UserIds - при условии, что UserName по-прежнему зависит от пользователей и от того, что зависит от вашей бизнес-логики. Я предлагаю вам оценить общее влияние, прежде чем принимать решение о внесении изменений.

Многие люди неизменно устанавливают ограничение PRIMARY KEY на любые ключевые столбцы, на которые ссылаются внешние ключи в других таблицах; другие люди предпочитают, чтобы «естественный ключ» всегда обозначался ПЕРВИЧНЫМ КЛЮЧОМ. Это в основном сводится к конвенции и эстетике и не обязательно делает какие-либо практические различия в любом случае. Я, конечно, не заметил, что на производительность запросов в SQL Server все время влияет ограничение PRIMARY KEY, а не ограничение UNIQUE.