Как смоделировать многие отношения «многие ко многим» в rdbms?

Question

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

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

student and tutor are in many-to-many
tutor and subject are in many-to-many
tutor and grade are also in many-to-many

A student can have many tutors for one subject of one grade.
There can be many tutors for one subject of one grade.
A subject of one grade can be taught by many tutors.

Выше приведены лишь несколько примеров отношений.

Мой вопрос заключается в том, как эффективно моделировать эти отношения? Должен ли я иметь одну соединительную таблицу для каждого из отношений или я должен объединить их в одну большую таблицу мостов?

Итак, если у меня есть таблица классов, then from the big bridge table I can get for which class which tutor taught which subject of what grade along with other details of the class.

Answer 1

Давайте предположим, что база данных еще не электронная, а вместо этого старый добрый шкаф для хранения документов. Давайте предположим, что база данных предназначена для библиотеки, и необходимо поддерживать несколько различных видов информации «многие ко многим»: авторы книг (соавторы имеют> 1 автора), читатели книг, читатели читателям, наличие книг в нескольких местах расположения библиотеки, ...

Ты когда-нибудь думал о том, чтобы спрятать всю эту различную информацию в один большой шкаф? Представляете, каковы последствия для его пользователей? Иногда вам будет запрещено делать что-то «читатели для книг» просто потому, что кто-то другой тут же делает что-то «читатели для читателей». Если и когда вам удастся получить доступ и, наконец, ваша очередь сделать что-то, скажем, «авторы книг», ваша работа будет замедлена, потому что все материалы «читатели книг» могут встать между ними, и вам придется потратить дополнительное время просто пропуская ненужные вещи. Если необходимо выполнить «операцию преобразования», скажем, обнаружен новый вид материала «многие ко многим», который необходимо интегрировать в единый шкаф для хранения документов, то база данных вся недоступен, когда выполняется операция преобразования (люди, добавляющие карточки того цвета, который еще не использовался). И т. Д. Эти нежелательные свойства переносятся почти на 1-1 к электронному эквиваленту.

Как сказал кто-то другой: не бойтесь таблиц. Это то, в чем хороша СУБД.

EDIT

Вкратце: просто держите его за одним столом на каждый тип факта и воздерживайтесь от (/ пытаясь обнаружить) отвратительных абстракций типа "они все просто свойства" / "все они просто некие" многие ко многим ... " отношение "/ .... Они гики, потому что конечный пользователь / бизнес-пользователь не будет "видеть" это. И поэтому в их создании нет никакой коммерческой ценности.