Дизайн таблицы базы данных

Question

В моей базе данных есть таблица, в которой хранятся музыканты, а также таблица событий. Я пытаюсь следить за тем, что музыканты играли на каком мероприятии. Какой самый эффективный способ сделать это? Должен ли я положить event_id в таблицу музыкантов и создать новую запись для каждого события, в котором играет музыкант? Должен ли я создать отдельную таблицу подстановки с event_id и musician_id и присоединиться к ней при попытке найти музыкантов, которые играли на определенном мероприятии? Проблема в том, что у меня сейчас около 50 музыкантов, и они могут играть 50 событий в год, это много избыточных данных, и есть вероятность, что некоторые из них будут играть в большем количестве событий, и это число может увеличиться до 100 музыкантов в какой-то момент. Есть идеи?

Answer 1

Я не буду выкладывать таблицы для вас, но основная структура будет:

musicians - подробности о художниках (например, 50 записей)
events - подробности особытие (например, 50 записей)
musicians_events - объединенная таблица, в которой перечисляются события, на которых исполнитель сыграл

Объединенная таблица будет состоять просто из 2 полей: идентификатор музыканта - идентификатор события, причем оба являются внешними ключамивернуться к соответствующей родительской таблице.

При указанном вами размере данных у вас будет 50 записей о музыкантах, 50 записей о событиях и, возможно, 2500 записей о событиях музыкантов, если каждый музыкант будет играть на каждом событии.

Answer 2

Вам нужна отдельная таблица поиска (также называемая соединительной таблицей), чтобы сопоставить отношения «многие ко многим» между музыкантами и событиями.

В таблице необходимо три поля: уникальный идентификатор, MusicianID и EventID.*

Answer 3

Я бы создал таблицу для таких событий, так что это всего лишь пример

**tbl_Event**
Event_ID
Event_Name
Event_Location


**tbl_Musician**
  musician_id
  musician_firstName
  musician_lastname

 ***tbl_join***
   event_ID
   musician_ID

Что-то в этом роде. Я не эксперт, но везде, где вы увидите много повторяющихся данных, вам следует избегать их.

Answer 4

Это, очевидно, am: n или ситуация соединения многие-ко-многим: вам нужны три таблицы:

• A musician таблица с musician_id.

• Таблица event с event_id.

• Таблица соединений (musician_events) с musician_id и event_id соба поля в качестве первичного ключа.

Логически у вас есть отношение многие ко многим.Физически у вас есть отношения один-ко-многим между musician и musician_events и отношения один-ко-многим между event и musician_events.

Это потому, что музыкант может участвовать во многихСобытия и события могут иметь много музыкантов.

 musician               musician_events            event
+-----------------+    +--------------------+    
| PK  musician_id |--->| PK FK  musician_id |    +--------------+
|     name        |    | PK FK  event_id    |<---| PK  event_id |
+-----------------+    +--------------------+    |     date     |
                                                 +--------------+

Answer 5

Если у вас может быть несколько музыкантов на мероприятии, то правильный способ смоделировать это второй вариант, который вы предложили - создать вторую таблицу с идентификатором musician_id и event_id, чтобы связать их.

Что касаетсяобъем данных - 50х50, это всего 2500 записей, что для MySQL - ничто.При правильном индексировании MySQL может легко обрабатывать миллионы записей в таблице.

Answer 6

Это звучит как типичное отношение «многие ко многим», когда у вас должна быть таблица для музыкантов, другая таблица для событий и третья таблица, в которой хранятся отношения между ними.В этой таблице будет указан musicianId и eventId.

Answer 7

Я бы создал стол музыкантов, имеющих отношение ко многим к таблице событий.

Это означает, что у вас будет таблица отношений, скажем, MusiciantEvent, которая содержит оба первичных ключа (MusiciantID и EventId)

Answer 8

Вы должны использовать таблицу соединений. Это вариант, который вы описали, когда у вас есть таблица с event_id и musician_id.

Это будет хорошо работать, если вы поместите правильные индексы в свои таблицы.