Можно ли использовать внешний ключ в качестве первичного ключа?

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

 Raphaël Althaus11 июн. 2012 г., 17:23
Entity Framework генерирует это (с первым кодом) для отношений zeroOrOne (и one)-to-one. Так что ... это возможно. Это лучший способ ... Это другой вопрос. Но это действительно. Я никогда не делал этого при создании своих собственных баз данных (но я даже никогда не думал об этом).

Ответы на вопрос(7)

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

a 1:1 relation. The two tables cannot be merged in one because of different permissions and privileges only apply at table level (as of 2017, such a database would be odd).

a 1:0..1 relation. Profile may or may not exist, depending on the user type.

performance is an issue, and the design acts as a partition: the profile table is rarely accessed, hosted on a separate disk or has a different sharding policy as compared to the users table. Would not make sense if the underlining storage is columnar.

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

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

 17 янв. 2019 г., 16:13
это полезно также для дизайна супертип-подтип. Первичный ключ таблицы подтипа должен быть ссылкой внешнего ключа на таблицу супертипа.

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

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

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

 10 февр. 2017 г., 11:04
Используя отдельную вторую таблицу, мы можем предотвратить запись в третью таблицу, которая разрешена только для людей, у которых есть запись во второй таблице.
 10 февр. 2017 г., 10:32
@ Тедди Точно так же я в основном согласен с тем, что ты сказал. Однако в исходном вопросе они утверждают, что ... его запись профиля создается автоматически ... & quot; подразумевается, что таблица профиля не является необязательной. В ситуации, когда таблица профиля была необязательной, тогда можно использовать ее как отдельную таблицу. Но опять же, они могли бы просто использовать пустые столбцы в одной таблице.
 09 февр. 2017 г., 12:28
Я согласен с вами в основном в том, что все данные в одной таблице имеют много преимуществ в виде дополнительных столбцов. Несмотря на то, что это .. », вы могли бы просто представить данные в одной таблице и получить тот же результат« ..: иметь отдельную таблицу может быть полезно, например, здесь, если запись в таблице профиля является необязательной. Например, у каждого клиента банка может не быть регистрации в интернет-банке. В этом случае таблица регистрации IB может быть использована для ограничения других таблиц, имеющих дополнительные дочерние записи. Опять же, здесь это можно сделать с новым PK для таблицы регистрации IB.
 10 февр. 2017 г., 16:40
Безусловно, но если мы объединяем таблицы 1 к 1, мы можем помешать людям с нулевыми значениями получить доступ к третьей (технически второй сейчас) таблице. Но заданный ОП вопрос содержит строку & quot; ... при регистрации ... ... его запись в профиле создается автоматически ... & quot ;, делая это лишним.
 13 авг. 2017 г., 20:00
Моя основная причина для рассмотрения этого заключается в том, что в хранилищах данных рекомендуется разделять таблицы фактов и измерений. Отдельные таблицы фактов и измерений являются полезными подсказками при работе с такими программами, как PowerPivot, PowerBI и Tableau.

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

profileID в качестве первичного ключа таблицыProfile

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

One could argue that a primary key is necessary as the target of any foreign keys which refer to it from other tables. A foreign key is a set of one or more columns in any table (not necessarily a candidate key, let alone the primary key, of that table) which may hold the value(s) found in the primary key column(s) of some other table. So we must have a primary key to match the foreign key. Or must we? The only purpose of the primary key in the primary key/foreign key pair is to provide an unambiguous join - to maintain referential integrity with respect to the "foreign" table which holds the referenced primary key. This insures that the value to which the foreign key refers will always be valid (or null, if allowed).

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

 04 авг. 2015 г., 16:06
Возможно - если у вас есть ограничение FK между User.UserID и Profile.UserID, то настоятельно рекомендуется иметь индекс для Profile.UserID. Почему бы не сделать этот основной кластеризованный индекс для таблицы Profile, сохранить второй индекс и массу ненужной работы для ядра базы данных?
Решение Вопроса

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

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

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

 24 сент. 2014 г., 09:14
Составной первичный ключ, состоящий из двух внешних ключей, также отлично подходит для реализации отношений «многие ко многим».
 14 нояб. 2017 г., 10:59
@ Rightfold, вы спасли майский день, спасибо.

Ваш ответ на вопрос