ключ природы vs auto_increment ключ как первичный ключ

Question

Моя проблема касается ключа природы и auto_increment integer в качестве первичного ключа.

Например, у меня есть таблицы A и B и A_B_relation. A и B могут быть некоторыми объектами, и A_B_realtion записывают отношение многих к большому числу A и B.

И A, и B имеют свой собственный глобальный уникальный идентификатор, такой как UUID. UUID доступен для пользователя, это означает, что пользователь может запросить A или B по UUID.

Существует два способа создания первичного ключа таблицы.

1. использовать значение auto_increment integer. A_B_relation ссылается на целое число как FK.
2. используйте UUID. A_B_relation ссылается на UUID как FK.

Например, пользователь хочет запросить информацию об ассоциированной информации B с помощью UUID от A.

В первом случае, поток запросов заключается в следующем:

First, query A's integer primary key by UUID from `A`. 

And then, query all the B's integer primary key from `A_B_relation`. 

At last, query all the B's info from `B`. 

В последнем случае поток, как показано ниже:

Query all the B's UUID from the `A_B_relation` by A's UUID. 

Query all the B's info from `B`. 

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

Answer 1

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

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

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

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

Естественный ключ имеет свой собственный смысл. Поэтому, когда дело доходит до поиска записей, более выгодно использовать естественные ключи над суррогатными ключами. Но со временем измените нашу логику программы, и мы должны изменить значение натурального ключа.Это будет сложно и вызовет каскадный эффект во всех отношениях внешних ключей. Мы можем преодолеть эту проблему с помощью суррогатного ключа. Поскольку суррогатный ключ не имеет отношения к остальным значениям строки, изменения в логике не будут влиять на суррогатный ключ.

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