Как проверить внешний ключ?

Question

[epitxx]

Структура:

Как гарантировать, что в таблице "успеваемость по предмету" student_id и task_id будут такими, что группа студента будет совпадать с группой, к которой относится задание?

Answer 1

[hacker2001]

Предмет не должен быть привязан к группе. Один предмет может преподаваться в разных группах (тут связь many-to many) и в разном объеме (количестве часов). Задание дается ученикам какой-то группы, те: id, group_id, subject_id

Comments

[epitxx]

У меня предполагается, что, допустим, кол-во часов по предмету может измениться именно в конкретной группе, поэтому предмет привязан к группе. Но не суть, даже если делать по другому, то проблема все равно остается.

То есть, к примеру, студент из группы 1 может сдавать задание, которое было выдано группе 2.

[hacker2001]

epitxx, для твоих целей есть хранимые процедуры и триггеры, те при инсерте в таблицу можно выполнять какую-то логику. Таблицу с успеваемостью можно переделать student_id, subject_id, дата сдачи, отметка. Дополнительные сущности надо вводить по мере появления в них необходимости. + можно пользоваться вспомогательными таблицами типа student_groups (id, student_id, group_id), group_subjects и тп

[hacker2001]

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

Answer 2

[mayton2019]

Не совсем понятно о каких гарантиях тут идет речь. Когда база создается с нуля (таблицы еще пустые) то после создания таблиц (или во время создания) делаются contstraints которые описывают связи между таблицами и реакцию на delete/update. Типа

.... CONSTRAINT `child_ibfk_1` FOREIGN KEY (`parent_id`) REFERENCES `parent` (`id`) ON DELETE
  RESTRICT...;

И после этого из базы нельзя удалять родительские ключи пока на них есть дочерние связи.