Схема дизайна: много ко многим плюс еще один ко многим - PullRequest
Новая
       28

Схема дизайна: много ко многим плюс еще один ко многим

2 голосов
/ 05 мая 2010

У меня есть этот сценарий, и я не уверен точно, как он должен быть смоделирован в базе данных. Объекты, которые я пытаюсь смоделировать: команды, игроки, членство в команде и список сборов, причитающихся каждому игроку в данной команде. Таким образом, сборы зависят как от команды, так и от игрока.

Итак, мой текущий подход следующий: 

**teams**
  id
  name

**players**
  id
  name

**team_players**
  id
  player_id
  team_id

**team_player_fees**
  id
  team_players_id
  amount
  send_reminder_on

Схема расположения ERD

В этой схеме team_players является таблицей соединений для teams и players. А в таблице team_player_fees есть записи, принадлежащие записям в соединительной таблице.

Например, игрок A входит в команду teamA и имеет сборы в размере 10 и 20 долларов США, подлежащие выплате в августе и феврале. PlayerA также входит в команду teamB, а сборы в размере 25 и 25 долларов США взимаются в мае и июне. Каждая комбинация игрок / команда может иметь различный набор сборов.

Вопросы:

  • Есть ли лучшие способы справиться с такими сценарий?
  • Есть ли термин для этого типа отношения? (так что я могу гуглить) Или знаете какие-нибудь ссылки с подобными структурами?

1 Ответ

0 голосов
/ 05 мая 2010

Таким образом, это прекрасный дизайн. Нередко у соединительной таблицы (таблицы пересечений AKA) есть собственные атрибуты, такие как joining_date, которые могут включать зависимые таблицы. Насколько я знаю, особого названия для этой договоренности нет.

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

...