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

Я не очень хорошо знаком с базами данных и теориями, с которыми они работают. Является ли медленнее с точки зрения производительности (вставка / обновление / запрос) использовать строки для первичных ключей, чем целые?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

По умолчанию ASPNetUserIds – это 128 строковых символов, и производительность очень хорошая.

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

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

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

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

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