Какую связь использовать между предметами и учителями, если один учитель ведет несколько предметов

Что проверяют

Умеете ли вы по формулировке задачи определить кратность связи и перевести её в таблицы и модели ORM. Следом обычно просят показать модели в Django или SQLAlchemy и спрашивают, куда положить данные самой связи, например число часов в неделю.

Как отвечать

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

Для «многие ко многим» нужна связующая таблица:

• teacher и subject: свои первичные ключи, ничего лишнего;
• teacher_subject: пары teacher_id, subject_id с внешними ключами на обе таблицы и составным первичным ключом или UNIQUE на пару, чтобы одна связь не записалась дважды;
• ON DELETE: решите заранее, что происходит при удалении учителя. Для связующей таблицы обычно CASCADE, иначе удаление упадёт на ограничении.

В Django это ManyToManyField на одной из моделей, промежуточную таблицу фреймворк создаёт сам. Когда у связи появляются свои атрибуты (часы, учебный год, класс), заводится явная модель и указывается через through=. В SQLAlchemy аналог: Table со связующими колонками и relationship(secondary=...), а для связи с атрибутами паттерн association object, отдельный класс-модель.

Добавьте про чтение: список учителей с предметами без подготовки даёт проблему N+1. В Django её снимает prefetch_related("subjects"), в SQLAlchemy selectinload.

Где спотыкаются

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

Ставят внешний ключ subject_id в таблицу учителей. Тогда учитель может вести только один предмет, то есть ровно то, чего условие не допускает.

Забывают про уникальность пары и про атрибуты связи. Без ограничения появляются дубли, а часы нагрузки пытаются хранить в модели учителя, хотя они принадлежат именно паре «учитель и предмет».