Всегда ли FK связан с полем "id" родительской таблицы? Плохая практика указывает на другое поле?

Question

представьте, что у меня есть таблица Nation (имя, iso_code_3, language, ..) и таблица Culture (languages) с полями (name, ...).Теперь мне нужно создать первичный ключ (полевой язык) в таблице Наций, который указывает на таблицу Культура (вы знаете, на каком языке говорят в каждой стране).введите в таблице Наций, следует ли ссылаться на поле «id» или я мог бы ссылаться на него непосредственно на поле «имя» (в обоих случаях, таблицы «Культура»)Например, я хочу получить строку Nation, содержащую язык, на котором говорят, было бы лучше сослаться на поле «имя».Таким образом, я бы избежал предложения INNER JOIN.

С уважением

Javi

Answer 1

Внешний ключ может ссылаться на любой ключ-кандидат в таблице, на которую он ссылается.Для простоты обычно имеет смысл выбрать один ключ на таблицу (обычно обозначаемый как «первичный» ключ), который будет последовательно использоваться для всех ссылок на внешние ключи этой таблицы - но нет абсолютной причины, почему вы должны это делать, если у вас естьвеская причина поступить иначе.Хорошие критерии для выбора используемых ключей: Знакомство, простота и стабильность .

"Id" - плохое имя для любого столбца - ключ или нет.

Answer 2

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

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

Как пример из другого поля, почтовые системы часто делают соединения по почтовому индексу, даже если нет главной таблицыпочтовые индексы в базе данных.Это действительно соединение многих ко многим.Иногда это правильно, но редко.Чаще всего правильно установить основную таблицу для идентифицируемой сущности (в вашем случае «Язык»), а затем выполнить два простых старых соединения FK-PK.Не беспокойтесь о трехстороннем соединении.Только с несколькими сотнями строк задержку не стоит рассматривать.

Answer 3

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

Answer 4

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

Внешний ключ всегда должен ссылаться на столбец в ссылочной таблице, который является по меньшей мере УНИКАЛЬНЫМ - первичный ключ всегда УНИКАЛЬЕН, так что «главный кандидат, конечно.

Не пытайтесь использовать ярлыки - базы данных SQL довольно хорошо разбираются в соединениях - не жертвуйте целостностью данных ради "быстрого" выигрыша .....

Answer 5

В вашем примере, у вас есть отношение «многие ко многим» , так как 1 страна может говорить на нескольких языках, на 1 языке можно говорить в нескольких странах. Таким образом, на самом деле вы должны быть представлены таблицей отношений , которая представляет ваше отношение m-to-m.
Эта таблица должна содержать PK обеих других таблиц.
Комбинация этих 2 FK по определению является PK вашей таблицы CountryLanguage.

Answer 6

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