В какой таблице лучше ставить внешний ключ при связи 1 к 1?

Question

[Drovosek01]

Здравствуйте.
Допустим есть таблица "Команды" и таблица "Тренеры". В одной команде может быть 1 тренер и у 1 тренера может быть 1 команда.
В какой из этих таблиц лучше создавать внешний ключ? Т.е. в таблице "Команды" лучше сделать поле "instructor_id" и FOREIGN KEY или лучше в таблице "Тренеры" сделать поле "team_id" и FOREIGN KEY.
Я догадываюсь, что это зависит от реализации/структуры данных и от того, в какую таблицу будут первыми попадать данные (чтобы потом на них делать внешний ключ), но может есть какое-то правило в этом плане?

Answer 1

[Decadal]

Вам нужно определить, какая сущность главная, а какая второстепенная для вашей программы. Как это будет выглядеть? Сначала заводится список тренеров а потом к ним крепятся команды? Или, наоборот, есть список команд и нужно создать им тренера? А может, это равнозначные сущности, и вы хотите иметь возможность завести список команд и список тренеров независимо друг от друга, а уже потом проставить связи?
Ставьте внешний ключ той сущности, которая не будет иметь множественной связи с большей вероятностью.
К примеру, если это соц сеть для тренеров, то вероятнее всего, тренер сможет добавлять список команд которых он тренировал. И тогда trainer_id пригодится в teams.
Но если ваша соцсеть вырастет и там будет база команд, которые тренер сможет выбрать из выпадающего списка (т.е. у команд тоже может быть много тренеров), то придется делать M:N. Ваш случай связи 1:1 возник только потому что ваше приложение еще недостаточно развилось.

Также не забудьте что 1 к 1 реализуется назначением UNIQ ограничения на внешний ключ. Иначе это 1 ко многим.

Comments

[Drovosek01]

А разве внешние ключи можно ставить потом? В SQLite не видел возможности такого сделать...

[Decadal]

Drovosek01, есть, это выставляется на уровне типов полей при создании таблицы.
trainer_id INT NULL DEFAULT NULL,
либо просто trainer_id INT, только тогда придется каждый раз передавать null явно: insert into teams (id, trainer_id) VALUES (1, null)

Answer 2

[qoso]

Речь не об одном внешнем ключе, это два РАЗНЫХ внешних ключа, и Вам необходимо создавать оба.

P.S. это при условии, что у вас обязательно должен быть тренер привязан к команде, а команда к тренеру

Comments

[Decadal]

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

[Drovosek01]

А как в таком случае добавлять данные, если у нас таблицы будут пустые?
Допустим добавляю я первую команду и должен указать id тренера, а тренеров еще нет, как быть?

[Decadal]

Drovosek01, ну, можно сделать внешний ключ nullable, т.е. у команды необязательно есть тренер \ у тренера необязательно есть команда. Иначе никак, если вы сделаете два ключа

[qoso]

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

[Decadal]

Лентюй, откуда у вас такая уверенность?

[Decadal]

create table test_table_1
(
	id serial not null
		constraint test_table_1_pkey
			primary key,
	t_2 integer
		constraint "idx-t2"
			references test_table_2
				on delete cascade
);

create index "idx-t2" on test_table_1 (t_2);

create table test_table_2
(
	id serial not null
		constraint test_table_2_pkey
			primary key,
	t_1 integer
		constraint "idx-t1"
			references test_table_1
				on delete cascade
);
create index "idx-t1"
	on test_table_2 (t_1);

Answer 3

[Константин Цветков]

Будет ситуация, которая не уложится в вашу модель.
Таблицы "Персона", "Роль", "Команда" и "Состав" (команда, персона и её роль) позволят избежать ситуации "играющий тренер" или "тренер по совместительству".

Comments

[Drovosek01]

Эм... что?

[timur_sh]

Drovosek01, вам предложили реализацию связи "много-ко-многим", т.е. самый общий случай. Я бы тоже так реализовал, потому что в случае с командами и тренерами высока вероятность, что появятся ситуации "в команде несколько тренеров" и т.д.
Если вы на 150% уверены, что такого не будет никогда, то таблица "Состав" не нужна.