Я рассматриваю возможность изменения некоторых таблиц, чтобы использовать nvarchar (50) в качестве первичного ключа вместо первичного ключа int. Использование идентификатора int для ключевого слова действительно не имеет значения, это строка, в которой я интересуюсь. Какого рода производительность будет происходить, или где вы исследуете это? Кроме вырезать и попробовать это.
Будет ли SQL Server 2005 наказывать меня за использование nvarchar (50) в качестве первичного ключа вместо целого?
Ответ 1
Вы столкнулись с одной из главных "священных войн" дизайна базы данных. Дискуссия, о которой вы говорите, является аргументом "суррогатный против естественного ключа", который бушевал до тех пор, пока были РСУБД (насколько я могу судить).
Дебаты по существу сводятся к тому, следует ли использовать представительский ключ (суррогат, например столбец IDENTITY), вместо использования фактических данных, которые однозначно описывают запись (естественный ключ).
Я скажу, что нет "правильного" ответа. Показатели эффективности являются артефактом платформы и должны оцениваться экспериментами, но производительность вряд ли будет главной проблемой.
Я считаю, что основным аргументом для суррогатных ключей является неизменность первичных ключей. Если вы решите использовать естественный ключ, вы откажитесь от возможности изменить этот ключ после его создания. Вы также отказываетесь от возможности, что в какой-то момент в будущем он может стать неидеальным. По этим причинам я обычно (не всегда) использую суррогатные ключи для большинства моих таблиц.
Однако, как я уже упоминал, есть очень давние дискуссии, в которых обсуждаются стратегии индексирования и приверженность нормальной форме, которые нужно читать, если вы так склонны.
Я бы заменил Google "суррогатом против естественных ключей". Вот несколько ссылок, которые помогут вам начать:
Надеюсь, что это поможет.
Ответ 2
Рассмотрим использование ключа суррогата (первичный ключ int) в качестве ключевого ключа/кластерного индекса. Проблема с использованием nvarchar (50) в качестве ключа первичного ключа/кластеризованного индекса заключается в том, что ваша таблица будет упорядочена по этому ключу, что означает, что он, вероятно, будет сильно фрагментирован и что любые другие индексы будут нести нагрузку для ссылки на этот тяжелый первичный ключ.
Другая проблема заключается в том, что, по-видимому, вам необходимо подключиться к другим таблицам с помощью такого типа значений, что является более дорогостоящей операцией по мере увеличения размера ключа.
Я думаю, что очень мало ситуаций, когда первичный ключ nvarchar (50) имел бы смысл.
Как правило, первичные ключи должны быть суррогатными, если у вас есть небольшой естественный неизменный ключ. Возможно, SSN, например, можно считать естественным неизменным ключом.
Ответ 3
Для производительности я обычно спрашиваю следующее:
-
сколько строк? 1000 или 1 000 000 или 10 000 000
-
на каком сервере он сидит? (память, дисковое пространство)
Я бы прокомментировал его, а затем посмотрю. Обычно для меня узким местом является не база данных, плохо написанный код, плохо развернутый и т.д. И т.д....
Ответ 4
Чтобы окончательно сжечь все аргументы, предложенные лидерами естественного ключевого решения (cf surrogate vs natural key war), и сделать это коротко, я должен сказать, что суррогатные ключи ВСЕГДА работают, в то время как естественные ключи имеют рыхлую тенденцию приводить к проблемам и разочарованиям, обычно в неожиданные моменты времени.
Я не говорю, что они являются оптимальным решением для каждой ситуации, но чтобы не потерять ваше (и другое) время, думая о правильных параметрах для лучшего естественного ключа при создании таблицы, просто выберите суррогат, и это сделано. И если ваша таблица, похоже, имеет естественный ключ, просто добавьте ее как поле с индексом (уникальный?).
И чтобы облегчить работу разработчиков, всегда используйте свое первое поле как первичный ключ, второй - предполагаемый/псевдо-натуральный ключ. Ваша таблица должна выглядеть так:
Tbl_whatever
id_whatever, unique identifier, primary key
code_whatever, nvarchar(your favorite length), indexed
.....
Где id_ является префиксом для первичного ключа, а code_ используется для "естественного" индексированного поля
Ответ 5
Почему UNICODE? например если бы я перевел английское слово на китайские символы Хан, будут ли они считаться дублирующими?
Зачем нужна переменная? Фиксированная ширина является хорошей физической характеристикой ключа.
Почему 50 символов? То, что много ключевых слов для пользователей (я согласен "int ID для ключа действительно не имеет отношения к данным" и думаю, что так называемые "суррогатные ключи" никогда не должны быть подвержены конечным пользователям, BTW).
Кроме того, для меня NVARCHAR(50) - это немного "запах": возможно, по умолчанию Microsoft, прямой порт из MS Access? Это не значит, что вы не продумали и не рассмотрели свой ключ, конечно, только одну из тех вещей, которые могут быть рассмотрены.
О, держись: ты имел в виду конкретно ПЕРВИЧНЫЙ КЛЮЧ, так? Предполагая, что вы явно используете свой один (для таблицы) кластеризованный индекс, обозначение AFAIK PRIMARY KEY не имеет физических последствий для SQL Server. Конечно, все ваши ключи-кандидаты должны покрываться ограничениями NOT NULL UNIQUE; тот, который вы выбираете для продвижения в PRIMARY, произволен.