Как выбрать мой первичный ключ?

Я нашел этот материал для чтения на выборе первичного ключа.

  • Есть ли сообщение руководства/блога о том, как выбрать первичный ключ для данной таблицы?
  • Должен ли я использовать автоинкрементный/сгенерированный ключ или я должен основывать первичный ключ на моделируемых данных (при условии, что у него действительно уникальное поле)?
  • Если первичный ключ всегда будет длинным для производительности, или я могу использовать внешний уникальный идентификатор в качестве первичного ключа, даже если это строка?

ОТВЕТЫ

Ответ 1

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

Ниже перечислены основные недостатки использования натурального ключа в качестве первичного ключа:

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

  • Часто бывает трудно получить действительно unique естественный ключ.

  • Природные ключи часто являются строками. Индекс в числовом поле будет намного более компактным, чем один в поле строки.

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

Ответ 2

Я использую суррогатные ключи, часто называемые нечувствительными ключами, состоящими из типа генерируемого автогенератора int/bigint.

Вот некоторые из причин, по которым мне нравятся эти ключи.

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

Ответ 3

Ключ - это набор атрибутов с двумя основными функциями: уникальность и минимальность. Минимальность означает, что ключ имеет только минимальное количество атрибутов, необходимых для обеспечения уникальности.

В качестве руководства для выбора хорошего ключа используются три критерия:

  • Знание - ключи должны быть значимыми и знакомыми людям, которые их используют.
  • Простота - ключи должны быть максимально простыми и лаконичными
  • Значения стабильности - значения должны редко меняться

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

Ответ 5

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

Что мне больше всего понравилось? Номер, предоставляемый службой как системный номер. Это работает хорошо. И с помощью простой таблицы перевода ключей можно использовать ключ пользователя (например, номер учетной записи), чтобы узнать, какой уникальный номер и какой объект данных (не обязательно таблица, потому что один и тот же уникальный ключ может применяться к нескольким таблицам, если объект данных разделяется на разные таблицы в зависимости от его типа).

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

Ответ 6

Я всегда выбираю uuid как первичный ключ. По сравнению с ключом int/long есть небольшие накладные расходы, но есть много преимуществ: вы не можете запускать переполнение типов, вы можете позже обходить базу данных без изменения первичных ключей, вы можете интегрироваться с другими системами и быть уверенными, что ваши первичные ключи всегда уникальны, uuid нельзя угадать и т.д.