У меня есть две таблицы:
В настоящее время я использую такой подход: каждая запись профиля имеет поле с именем "userId" в качестве внешнего ключа, которое ссылается на таблицу User. Когда пользователь регистрируется, его профиль автоматически создается.
Я запутался с предложением моего друга: иметь поле "userId" в качестве внешнего и первичного ключа и удалить поле "profileId". Какой подход лучше?
Внешние ключи почти всегда являются "Разрешать дубликаты", что делает их непригодными в качестве первичных ключей.
Вместо этого найдите поле, которое однозначно идентифицирует каждую запись в таблице, или добавьте новое поле (целочисленное с автоинкрементом или GUID), которое будет действовать в качестве первичного ключа.
Единственным исключением из этого являются таблицы с отношением " один к одному", где внешний ключ и первичный ключ связанной таблицы - это одно и то же.
Первичные ключи всегда должны быть уникальными, внешние ключи должны допускать неединственные значения, если таблица является отношением "один ко многим". Вполне нормально использовать внешний ключ в качестве первичного ключа, если таблица связана взаимно-однозначным отношением, а не отношением "один ко многим". Если вы хотите, чтобы одна и та же пользовательская запись имела возможность иметь более одной связанной записи профиля, перейдите с отдельным первичным ключом, в противном случае придерживайтесь того, что у вас есть.
Обычно считается, что плохая практика имеет отношения "один к одному". Это связано с тем, что вы можете просто иметь данные, представленные в одной таблице, и достичь того же результата.
Однако существуют случаи, когда вы не можете вносить эти изменения в таблицу, на которую вы ссылаетесь. В этом случае нет проблем с использованием внешнего ключа в качестве первичного ключа. Это может помочь создать составной ключ, состоящий из автоматического приращения уникального первичного ключа и внешнего ключа.
В настоящее время я работаю над системой, в которой пользователи могут входить в систему и создавать код регистрации для использования с приложением. По причинам, в которые я не буду входить, я не могу просто добавить столбцы, необходимые для таблицы users. Поэтому я собираюсь с одного на один маршрут с таблицей кодов.
Да, внешний ключ может быть первичным ключом в случае отношения один к одному между этими таблицами
Да, законно иметь первичный ключ, являющийся внешним ключом. Это редкая конструкция, но она применяется для:
соотношение 1:1. Две таблицы не могут быть объединены в одну из-за того, что разные разрешения и привилегии применяются только на уровне таблицы (по состоянию на 2017 г. такая база данных будет нечетной).
a 1: 0..1. Профиль может быть или не существовать, в зависимости от типа пользователя.
производительность - это проблема, и дизайн действует как раздел: редко можно получить доступ к таблице профилей, размещаться на отдельном диске или иметь другую политику очертания по сравнению с таблицей пользователей. Не имеет смысла, если подчеркивающее хранилище является столбчатым.
Я бы этого не сделал. Я бы сохранил profileID как первичный ключ таблицы Profile
Внешний ключ - это просто ссылочное ограничение между двумя таблицами
Можно утверждать, что первичный ключ необходим как цель любых внешних ключей, которые ссылаются на него из других таблиц. Внешний ключ - это набор из одного или нескольких столбцов в любой таблице (не обязательно ключ-кандидат, не говоря уже о первичном ключе этой таблицы), который может содержать значения (-и), найденные в столбцах (-ях) первичного ключа некоторых другой таблица. Поэтому у нас должен быть первичный ключ для соответствия внешнему ключу. Или мы должны? Единственная цель первичного ключа в паре первичного ключа/внешнего ключа - обеспечить однозначное соединение - поддерживать ссылочную целостность по отношению к "чужой" таблице, которая содержит ссылочный первичный ключ. Это гарантирует, что значение, к которому относится внешний ключ, всегда будет действительным (или null, если разрешено).
Это зависит от бизнеса и системы.
Если ваш userId уникален и будет уникальным все время, вы можете использовать userId в качестве основного ключа. Но если вы когда-либо захотите расширить свою систему, это усложнит ситуацию. Я советую вам добавить внешний ключ в пользователе таблицы, чтобы установить связь с профилем таблицы вместо добавления внешнего ключа в профиль таблицы.
Краткий ответ: ЗАВИСИТСЯ.... В этом конкретном случае это может быть хорошо. Тем не менее, эксперты будут рекомендовать против этого почти каждый раз; в том числе ваш случай.
Зачем?
Ключи редко бывают уникальными в таблицах, где они являются иностранными (возникли в другой таблице). Например, идентификатор элемента может быть уникальным в таблице ITEMS, но не в таблице ORDERS, поскольку элемент такого же типа, скорее всего, будет существовать в другом порядке. Аналогично, идентификаторы заказов могут быть уникальными (возможно) в таблице ORDERS, но не в какой-либо другой таблице, такой как ORDER_DETAILS, где может существовать заказ с несколькими позициями, и для запроса определенного элемента в определенном порядке необходимо объединить два FK (order_id и item_id) в качестве PK для этой таблицы.
Я не эксперт по БД, но если вы можете логически обосновать использование автоматически сгенерированного значения в качестве вашего PK, я бы это сделал. Если это не практично, то комбинация из двух (или, может быть, больше) FK может служить вашим ПК. НО, я не могу вспомнить ни одного случая, когда одно значение FK может быть оправдано как PK.