Внешний ключ SQL для первичного ключа или уникального столбца

Question

Предположим, у меня есть две таблицы, таблица A и таблица B, и эта таблица A имеет следующие столбцы:

COLUMNS (id INT PRIMARY KEY, name VARCHAR(200) UNIQUE)

Я хочу создать столбец в таблице B, который ссылается на строку таблицы A, используявнешний ключ.В большинстве случаев, когда я просматриваю строку в таблице BI, я также хочу получить поле имени в строке таблицы A, на которую оно ссылается.Скорость поиска (но не вставок) является проблемой.

Было бы лучше использовать первичный ключ таблицы A в качестве внешнего ключа, а затем использовать JOIN, чтобы ввести значение поля имени, илиБыло бы лучше использовать поле имени в качестве внешнего ключа, чтобы эти данные уже присутствовали при поиске строки в таблице B?

Answer 1

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

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

Answer 2

будет лучше использовать первичный ключ таблицы A в качестве внешнего ключа, а затем использовать JOIN для ввода значения поля имени, в противном случае просто поместите все в таблицу B

Answer 3

В вашем примере "имя" - это столбец, который можно обнулять, поэтому он не является ключом-кандидатом. Предполагается, что ограничение внешнего ключа ссылается на ключ-кандидат (например, в данном случае «Id»). Я рекомендую либо изменить таблицу, чтобы сделать «name» необнуляемым, либо использовать ссылочный Id.

Обнуляемые ограничения UNIQUE и FOREIGN KEY в SQL могут быть по-разному реализованы в разных продуктах баз данных. Их значение иногда неоднозначно, а результаты их использования часто противоречивы и, вероятно, не соответствуют действительности.

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