Объяснение суррогатного ключа "предпочтения"

Question

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

Тем не менее, я либо тупой, либо слепой, но не вижу повода иметь суррогатный ключ всегда!

Скажем, у вас есть 3 таблицы в конфигурации, как это:

Зачем мне суррогатный ключ для этого? Я имею в виду, что имеет смысл не иметь его.

Кроме того, кто-то может объяснить, почему первичные ключи никогда не должны меняться в соответствии с пуристами суррогатных ключей? Я имею в виду, если я скажу color_id VARCHAR(30) и ключ black и мне больше не нужен черный, потому что я меняю его на charcoal почему плохая идея изменить black ключ к charcoal и все ссылающиеся столбцы тоже?

РЕДАКТИРОВАТЬ: Просто заметил, что мне даже не нужно менять это! Просто создайте новый, измените ссылочные столбцы (как я бы сделал с суррогатным ключом) и оставьте старый в покое....

В мантре суррогатного ключа мне нужно создать дополнительную запись, скажем, id=232 а также name=black, Как это мне на самом деле полезно? У меня в таблице есть запасной ключ, который мне больше не нужен. Также мне нужно присоединиться, чтобы получить цветное имя, в противном случае я могу оставаться за одним столом и веселиться?

Пожалуйста, объясните, например, 5-летнему ребенку, и имейте в виду, что я не пытаюсь сказать "суррогатный ключ плох", я пытаюсь понять, почему кто-то говорит такие вещи, как "всегда используйте суррогатный ключ!".

Answer 1

Суррогатные ключи полезны, когда существует неоптимальный естественный ключ: не больше, не меньше. Субоптимальным естественным ключом будет GUID или varchar или иным образом широкий / неупорядоченный.

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

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

Для таблицы со связью (многие-многие) она вам не нужна: SQL: Вам нужен автоинкрементный первичный ключ для таблиц "многие-многие"?, Для таблицы с 2 столбцами типа int накладные расходы составляют дополнительно 50% данных для суррогатного столбца (с учетом целочисленных значений и игнорированием метаданных строки)

Answer 2

Ну, я больше о натуральных ключах сам:)

Но суррогатные ключи могут иметь свои преимущества, даже если вы, как и я, хотите идти "натурально" до конца:)

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

Table Fee (
foreign_key1,
foreign_key2,
foreign_key3,
value)

запись определяется / идентифицируется тремя внешними ключами, но в то же время вы можете иметь не более двух из них, чтобы быть нулевыми. Таким образом, вы не можете создать их как первичные ключи (вы просто поместите уникальный в 3 столбца). Чтобы иметь первичный ключ в этой таблице, единственный способ сделать это - использовать суррогат:)

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

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

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

Answer 3

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

patient_name
address
mobile_no
email_address

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

Здесь вы можете написать суррогатный ключ в верхней части фактических данных

patient_no----->primary key[surrogate key]
patient_name ---->pk
address
mobile_no--->pk
email_address