Reputation: 1491

Database Table Design

I have a table in my database that stores musicians in a table as well as an event table. What I'm trying to do is keep track of what musicians played at what event. What is the most efficient way to do this? Should I put the event_id in the musician table and create a new record for each event the musician plays in? Should I create a separate lookup table with the event_id and the musician_id and join on the table when trying to get the musicians that played at a particular event? The problem is I have about 50 musicians currently and they could be playing 50 events per year, that's a lot of redundant data and there's also the probability that some will play in more events and that number might increase to 100 musicians at some point. Any ideas?

Upvotes: 0

Answers (8)

Olivier Jacot-Descombes

Reputation: 112712

This is clearly a m:n or many-to-many join situation: You need three tables:

A musician table with a musician_id.
An event table with an event_id.
A junction table (musician_events) with a musician_id and an event_id with both fields as primary key.

Logically you have a many-to-many relationship. Physically you have a one-to-many relationship between musician and musician_events and a one-to-many relationship between event and musician_events.

This is because a musician can participate in many events and an event can have many musicians.

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

Upvotes: 0

Tim

Reputation: 1239

I would create a table for events like so this is just a sample

**tbl_Event**
Event_ID
Event_Name
Event_Location


**tbl_Musician**
  musician_id
  musician_firstName
  musician_lastname

 ***tbl_join***
   event_ID
   musician_ID

Something to that nature. I am no expert but anywhere that you are going to see a lot of duplicate data you should try avoid it.

Upvotes: 0

Massimiliano Peluso

Reputation: 26737

I would create a table musicians with a many to many relationship to the event table.

That's mean that you will have a relationship Table called let's say MusiciantEvent that contains both the primary keys (MusiciantID and EventId)

Upvotes: 0

Eric Petroelje

Reputation: 60529

If you can have multiple musicians at an event, then the right way to model this is the second option you suggested - creating a second table with a musician_id and an event_id to relate them.

As for the amount of data - 50 x 50 is only 2,500 records, which is nothing for MySQL. With proper indexing, MySQL can easily handle millions of records in a table.

Upvotes: 0

jamesaharvey

Reputation: 14291

This sounds like a typical many-to-many relationship where you should have a table for musicians, another table for events and then a third table that stores the relationship between them. That table would have a musicianId and an eventId.

Upvotes: 0

Marc B

Reputation: 360842

I won't lay out the tables for you, but the basic structure would be:

musicians - details about the artists (eg. 50 records)
events - details about an event (e.g. 50 records)
musicians_events - joint table that lists which events an artist played at

The joint table would consist simply of 2 fields: musician ID an event ID, both being foreign keys back to their respective parent table.

With your stated data size, you'd have 50 musician records, 50 event records, and potentially, 2,500 musician-event records if every musician played at every event.

Upvotes: 2