Строки как первичные ключи в базе данных SQL

Используйте sp_executesql для выполнения любого SQL, например

DECLARE @tbl    sysname,
        @sql    nvarchar(4000),
        @params nvarchar(4000),
        @count  int

DECLARE tblcur CURSOR STATIC LOCAL FOR
   SELECT object_name(id) FROM syscolumns WHERE name = 'LastUpdated'
   ORDER  BY 1
OPEN tblcur

WHILE 1 = 1
BEGIN
   FETCH tblcur INTO @tbl
   IF @@fetch_status <> 0
      BREAK

   SELECT @sql =
   N' SELECT @cnt = COUNT(*) FROM dbo.' + quotename(@tbl) +
   N' WHERE LastUpdated BETWEEN @fromdate AND ' +
   N'                           coalesce(@todate, ''99991231'')'
   SELECT @params = N'@fromdate datetime, ' +
                    N'@todate   datetime = NULL, ' +
                    N'@cnt      int      OUTPUT'
   EXEC sp_executesql @sql, @params, '20060101', @cnt = @count OUTPUT

   PRINT @tbl + ': ' + convert(varchar(10), @count) + ' modified rows.'
END

DEALLOCATE tblcur
163
задан mainstringargs 5 February 2009 в 19:40
поделиться

11 ответов

Технически да, но если строка имеет смысл быть первичным ключом затем, необходимо, вероятно, использовать его. Это все зависит от размера таблицы, Вы делаете его для и длина строки, которая будет первичным ключом (более длинные строки == тяжелее для сравнения). Я не обязательно использовал бы строку для таблицы, которая имеет миллионы строк, но объем замедления производительности, которое Вы получите при помощи строки на меньших таблицах, будет крохотным к головным болям, от которых Вы можете страдать при наличии целого числа, которое ничего не означает относительно данных.

177
ответ дан Jamie Lester 4 November 2019 в 17:01
поделиться

Могло быть очень большое недоразумение, связанное со строкой в базе данных. Почти все думали, что представление базы данных чисел более компактно, чем для строк. Они думают, что в числах дб-s представлены как в памяти. НО это не верно. В большинстве случаев представление числа больше близко к строке как представление относительно другого.

скорость использования числа или строки более зависит от индексации затем сам тип.

0
ответ дан takacsot 4 November 2019 в 17:01
поделиться

С точки зрения производительности - Да строка (PK) замедлит производительность по сравнению с производительностью, достигнутой с помощью целого числа (PK), где PK---> Первичный ключ.

С точки зрения требования - Хотя это не часть Вашего вопроса все еще, я хотел бы упомянуть. Когда мы обрабатываем огромные данные через различные таблицы, мы обычно ищем вероятный набор ключей, которые могут быть установлены для конкретной таблицы. Это, прежде всего, потому что существует много таблиц, и главным образом каждый или некоторая таблица были бы связаны с другим через некоторое отношение (понятие Внешнего ключа). Поэтому мы действительно не можем всегда выбирать целое число в качестве Первичного ключа, скорее мы идем для комбинации 3, 4 или 5 атрибутов как первичный ключ для этого таблицы. И те ключи могут использоваться в качестве внешнего ключа, когда мы связали бы записи с некоторой другой таблицей. Это делает полезным связать записи через различные таблицы при необходимости.

Поэтому для Оптимального Использования - Мы всегда делаем комбинацию 1 или 2 целых чисел с 1 или 2 строковыми атрибутами, но снова только если оно требуется.

1
ответ дан 4 November 2019 в 17:01
поделиться

Какова Ваша причина того, чтобы иметь строку как первичный ключ?

я просто установил бы первичный ключ к автоматическому увеличивающему целочисленному полю и поместил бы индекс на строковое поле.

Тот путь, если Вы делаете поиски на таблице, они должны быть относительно быстрыми, и все Ваши соединения, и нормальные взлеты взгляда будут незатронуты в своей скорости.

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

1
ответ дан John Bubriski 4 November 2019 в 17:01
поделиться

Индексы подразумевают много сравнений.

Как правило, строки длиннее, чем целые числа и правила сопоставления могут быть применены для сравнения, так сравнение представляет в виде строки, обычно более в вычислительном отношении интенсивная задача, чем сравнение целых чисел.

Иногда, тем не менее, это быстрее для использования строки в качестве первичного ключа, чем сделать дополнительное соединение с string to numerical id таблица.

2
ответ дан Quassnoi 4 November 2019 в 17:01
поделиться

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

Одна вещь не упустить, тем не менее, состоит в том, если Вы кластеризировали индексы на любом ключе и делаете большие количества вставок, которые непоследовательны в индексе. Каждая записанная строка заставит индекс переписывать. если Вы делаете, пакет вставляет, это может действительно замедлить процесс.

2
ответ дан Yes - that Jake. 4 November 2019 в 17:01
поделиться

Слишком много переменных. Это зависит от размера таблицы, индексов, природы домена строкового ключа...

Обычно , целые числа будут быстрее. Но различия будут достаточно значительными для заботы? Трудно сказать.

кроме того, какова Ваша мотивация для выбора строк? Числовые автоинкрементные ключи часто так легче также. Это - семантика? Удобство? Проблемы Репликации / разъединенные проблемы? Ваш ответ здесь мог ограничить Ваши опции. Это также напоминает третью "гибридную" опцию, которую Вы забываете: Гуиды.

5
ответ дан Joel Coehoorn 4 November 2019 в 17:01
поделиться

Не имеет значения, что Вы используете в качестве первичного ключа, пока это УНИКАЛЬНО. Если Вы заботитесь о скорости, или хорошее проектирование баз данных используют интервал, если Вы не планируете тиражирование данных, то используйте GUID.

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

6
ответ дан Al Katawazi 4 November 2019 в 17:01
поделиться

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

я также хочу указать, что лучший из обоих миров должен часто использовать ключ автопостепенного увеличения (или в некоторых специализированных случаях, GUID) как PK и затем помещать уникальный индекс на естественный ключ. Вы получаете более быстрые соединения, Вы надеваете; t получают дублирующиеся записи, и Вы не должны обновлять миллион дочерних записей потому что измененное название компании.

12
ответ дан HLGEM 4 November 2019 в 17:01
поделиться

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

68
ответ дан Tohid 4 November 2019 в 17:01
поделиться

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

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

Делают люди ввода данных или автоматические источники данных всегда обеспечивают значение для воображаемого естественного ключа, или иногда опускается? Это находится иногда неправильно во входных данных? Если так, как ошибки обнаружены и исправлены?

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

, Если Вы не можете доверять естественному ключу, изобретите суррогат. При изобретении суррогата Вы могли бы также изобрести целое число. Затем необходимо волноваться о whther для сокрытия суррогата от пользовательского сообщества. Некоторые разработчики, которые не скрыли суррогатный ключ, приехали для сожаления о нем.

4
ответ дан Walter Mitty 4 November 2019 в 17:01
поделиться
Другие вопросы по тегам:

Похожие вопросы: