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

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

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

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

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

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

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

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

Table Fee (
foreign_key1,
foreign_key2,
foreign_key3,
value)

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

Теперь ... почему бы не изменить первичный ключ ... Это можно считать довольно философским ... Я вижу это таким образом, надеюсь, что это будет иметь смысл ... Первичный ключ сам по себе - это не только комбинация of unique + not null, это больше о «реальной сути записи», о том, что она определяет запись в ядре. В этом смысле это не то, что вы могли бы легко изменить, не так ли?

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

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

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

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