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

Question

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

Answer 1

Внешние ключи почти всегда «Разрешить Дубликаты», который сделает их непригодными в качестве первичных ключей.

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

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

Answer 2

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

profileID Внешний ключ просто реляционная между двумя таблицами

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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

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

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

Answer 6

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

Answer 7

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

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

• a 1: 0..1 отношение. Профиль может или не может существовать в зависимости от типа пользователя.

• Производительность является проблемой, и дизайн действует как раздел: таблица профиля редко обращается к ней, размещается на отдельном диске или имеет другую политику очертания по сравнению с таблицей пользователей. Не имеет смысла, если подчеркивающее хранилище является столбчатым.