Наилучшая практика выбора первичных ключей в реляционной БД. Какое решение является наиболее разумным?

Question

Я проектирую реляционную БД, и у меня возникают следующие сомнения относительно того, как лучше всего обрабатывать первичные ключи

У меня есть несколько таблиц, в которых единственный способ получить первичный ключ - это установить BIGINT autoincrement столбец с именем id.

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

Мой вопрос: какова лучшая практика в этом случае? Я все еще использую столбец BIGINT autoincrement с именем id или в этом случае лучше использовать однозначные данные в качестве первичного ключа?

Answer 1

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

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

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

И в настоящее время это стандартная практика в хранилищах данных, поэтому разработчики привыкли видеть их СК колонны.

Лучшая практика? Вероятно. Общепринятая практика? Определенно. Go с автоинкрементами.

Answer 2

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

Основной продукт этого является то, что ключи базы данных сами по себе не должны нести информацию. Они должны «однозначно идентифицировать ряд» и не более того. Итак, целое число с автоинкрементом - это хорошая вещь для использования в качестве первичного ключа. Затем поместите индекс ... возможно, индекс UNIQUE ... на country_code.

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

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