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

Ответ 1

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

Ответ 2

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

Ответ 3

Вставка в таблицу с кластеризованным индексом, где вставка происходит в середине последовательности, НЕ ДЕЛАЕТ, чтобы индекс был переписан. Это не приводит к перезаписи страниц, содержащих данные. Если на странице, где будет идти строка, будет место, то она будет размещена на этой странице. Одна страница будет переформатирована, чтобы разместить строку в нужном месте на странице. Когда страница будет заполнена, произойдет разделение страницы, причем половина строк на странице перейдет на одну страницу, а половина - на другой. Затем страницы переадресовываются в связанный список страниц, содержащих данные таблиц с кластерным индексом. В лучшем случае вы в итоге напишите 2 страницы базы данных.

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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

Как правило, целые числа будут быстрее. Но разве разница будет достаточно большой, чтобы заботиться? Трудно сказать.

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

Ответ 7

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

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

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

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

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

Ответ 8

Индексы подразумевают большое количество сравнений.

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

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

Ответ 9

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

Ответ 10

Две причины использования целых чисел для столбцов PK:

• Мы можем установить идентификатор для целочисленного поля, которое автоматически увеличивается.

• Когда мы создаем PK, db создает индекс (Cluster или Non Cluster), который сортирует данные перед хранением в таблице. Используя идентификатор на ПК, оптимизатору не нужно проверять порядок сортировки перед сохранением записи. Это повышает производительность на больших таблицах.

Ответ 11

В чем причина того, что в качестве первичного ключа есть строка?

Я бы просто установил первичный ключ в поле auto incrementing integer и поместил индекс в поле строки.

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

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

Ответ 12

С точки зрения производительности - Yes string (PK) замедляет производительность по сравнению с производительностью, достигаемой с использованием целого числа (PK), где PK --- > Основной ключ.

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

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

Ответ 13

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

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

Ответ 14

По умолчанию ASPNetUserIds - это 128 строк char, и производительность просто прекрасна.

Если ключ должен быть уникальным в таблице, он должен быть ключом. Вот почему;

первичный строковый ключ = правильные отношения БД, 1 строковый ключ (первичный) и 1 строковый индекс (первичный).

Другим вариантом является типичный int Key, но если строка HAS является уникальной, вам все равно, вероятно, придется добавить индекс из-за безостановочных запросов для проверки или проверки того, что его уникальный.

Таким образом, использование ключа int ident = Неправильные отношения DB, 1 int key (Primary), 1 int index (Primary), Вероятно, уникальная строка Index и вручную для проверки одной и той же строки не существует ( возможно, что-то вроде проверки sql).

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