Это нормально иметь внешний ключ в качестве первичного ключа?

У меня есть таблица "пользователь" (имя пользователя, пароль) и таблица "профиль" (profileId, пол, дата рождения,...). В настоящее время я использую этот подход: каждая запись профиля имеет поле с именем "userId" в качестве внешнего ключа, который ссылается на таблицу пользователей. Когда пользователь регистрируется, его запись профиля создается автоматически. Я смущен своим предложением друга: иметь поле "userId" в качестве внешнего и первичного ключа и удалить поле "profileId". Какой подход лучше ?

7 57
database foreign-keys primary-key

7 ответов:

внешние ключи почти всегда "разрешают дубликаты", что делает их непригодными в качестве первичных ключей.

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

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

80

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

24

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

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

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

3

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

2

Я бы не стал этого делать. Я бы сохранил profileID как первичный ключ таблицы Profile

внешний ключ-это просто реляционная связь между двумя таблицами

можно утверждать, что первичный ключ необходим как цель любых внешних ключей, которые ссылаются на него из других таблиц. Внешний ключ-это набор из одного или нескольких столбцов в таблице (не обязательно потенциальные ключи, не говоря уже о первичный ключ этой таблицы), который может содержать значение(ы) в первичные ключевые столбцы некоторых других таблиц. Поэтому мы должны иметь первичный ключ, чтобы соответствовать внешнему ключу. Или мы должны? Единственная цель первичного ключа в паре первичный ключ / внешний ключ состоит в том, чтобы обеспечить однозначное соединение - поддерживать ссылочную целостность по отношению к "внешней" таблице, которая содержит ссылочный первичный ключ. Это гарантирует, что значение, на которое ссылается внешний ключ всегда будет действовать (или null, если разрешенный.)

http://www.aisintl.com/case/primary_and_foreign_key.html

1

Это зависит от бизнеса и системы.

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

1

да, законно иметь первичный ключ, являющийся внешним ключом. Это редкая конструкция, но она применяется для:

  • соотношение 1:1. Две таблицы не могут быть объединены в одну из-за разного разрешения и привилегии действуют только на уровне таблицы (с 2017 года, это будет странно).

1