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

Question

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

Answer 1

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

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

Answer 4

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

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