SQL внешнего ключа на первичный ключ или уникальный колонке

Question

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

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

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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