SQL Server 2005 оштрафует меня за использование nvarchar (50) как первичный ключ вместо целого числа?

Для производительности я обычно спрашиваю следующее:

• сколько строк? 1,000 или 1,000,000 или 10,000,000??

• на каком сервере это находится? (память, дисковое пространство)

Я представил бы его и затем видел бы. Обычно для меня, узкое место не является базой данных, оно плохо написало код, плохо развернутый и т.д. и т.д...

Рассмотрите использование суррогатного ключа (международный первичный ключ) как первичный ключ / ключ кластерного индекса. Проблема использовать nvarchar (50) в качестве первичного ключа / ключ кластерного индекса состоит в том, что Ваша таблица будет заказана тем ключом, что означает, что это, вероятно, будет высоко фрагментировано, и что любые другие индексы будут иметь нагрузку ссылки на этот тяжелый первичный ключ.

Другая проблема - то, что, по-видимому, необходимо ПРИСОЕДИНИТЬСЯ на других таблицах этим типом значения, которое является более дорогой операцией, когда размер ключа растет.

Я думаю, что существует очень немного ситуаций, где nvarchar (50) первичный ключ имел бы смысл.

Обычно первичные ключи должны быть суррогатом, ЕСЛИ у Вас нет маленького естественного неизменного ключа. Возможно, SSN, например, можно было считать естественным неизменным ключом.

Для определенного сжигания всех аргументов, предложенных лидерами естественного ключевого решения (cf суррогат по сравнению с естественной ключевой войной), и сделать это коротким, я должен сказать, что суррогатные ключи ВСЕГДА работают, в то время как естественные ключи имеют loosy тенденцию привести к проблемам и разочарованию, обычно в неожиданные времена.

Я не говорю, что они - оптимальное решение каждой ситуации, но постараться не освобождать Ваш (и других) время, думая о надлежащих параметрах для лучшего естественного ключа при составлении таблицы, просто выбирают суррогат, и это сделано. И если Ваша таблица, кажется, имеет надлежащий естественный ключ, просто добавьте его как поле с (уникальный?) индекс.

И помочь разработчикам, всегда имейте свое первое поле как первичный ключ, при этом второй будь воображаемым/псевдо естественным ключом. Ваша таблица должна просто быть похожей на это:

Tbl_whatever
     id_whatever, unique identifier, primary key
     code_whatever, nvarchar(your favorite length), indexed
     .....

Где id_ является префиксом для первичного ключа, и code_ используется для "естественного" индексируемого поля

Почему UNICODE? например, если бы я перевел английское слово в китайские ханьские символы, то они считались бы дубликатами?

Почему переменная? Фиксированная ширина является хорошими физическими характеристиками ключа.

Почему 50 символов? Это - большое манипулирование для пользователей (я соглашаюсь, что "международный идентификатор для ключа действительно является несоответствующими данными", и думайте, что такие так называемые 'суррогатные ключи' никогда не должны выставляться конечным пользователям, BTW).

Кроме того, для меня NVARCHAR(50) что-то вроде 'запаха': значение по умолчанию Microsoft, прямой порт от Доступа MS, возможно? Это не означает, что Вы не уделили должное внимание и соображение к Вашему ключу, конечно, только одна из тех вещей, возможно, рассмотреть.

О, держитесь: Вы имели в виду специфически PRIMARY KEY, правильно? Принятие Вас явно использует Ваш один (на таблицу) кластерный индекс, AFAIK, обозначение PRIMARY KEY не имеет никаких физических последствий на земле SQL Server. Конечно, все Ваши ключи-кандидаты должны быть покрыты ограничениями UNIQUE NOT NULL; тот, который Вы принимаете решение способствовать ПЕРВИЧНОМУ КЛЮЧУ, произволен.