+3Hello everyone,
I'm looking to build a base to collect a long list of songs that our team members play during the day. A team member is a member of a group, and some groups have several members who play multiple songs during their work schedule. I have explored various solutions online, but it appears that the solution we need is more advanced.
Any assistance would be greatly appreciated.
Best regards
+18Simple approach would be two tables:
Team Members (unique list) <-linked-> Songs (unique list)
Team members would have a "Group" (or "Team") field that's a single-select dropdown that you can use to group by in a grid view in order to see team members under each group and their linked songs.
Songs would have a lookup on the Team Member linked record to pull in Group so that you can group songs by Group. If you don't want groups created when team members choose the same song record, either make the Songs table not unique (not ideal) or use a junction table approach.
With a junction table, you would have TMs (unique) <-> TM Songs (junction) <-> Songs (unique). There are other benefits to a junction table besides cleaner group bys such as if you wanted each team member to be able to add notes/ratings/other details to their chosen songs that remain separated from other team members. You may not need the slight boost in complexity right off the bat and could get away with 2 tables. More info: https://support.airtable.com/docs/understanding-linked-record-relationships-in-airtable#manytomany-relationships-and-junction-tables
+3Simple approach would be two tables:
Team Members (unique list) <-linked-> Songs (unique list)
Team members would have a "Group" (or "Team") field that's a single-select dropdown that you can use to group by in a grid view in order to see team members under each group and their linked songs.
Songs would have a lookup on the Team Member linked record to pull in Group so that you can group songs by Group. If you don't want groups created when team members choose the same song record, either make the Songs table not unique (not ideal) or use a junction table approach.
With a junction table, you would have TMs (unique) <-> TM Songs (junction) <-> Songs (unique). There are other benefits to a junction table besides cleaner group bys such as if you wanted each team member to be able to add notes/ratings/other details to their chosen songs that remain separated from other team members. You may not need the slight boost in complexity right off the bat and could get away with 2 tables. More info: https://support.airtable.com/docs/understanding-linked-record-relationships-in-airtable#manytomany-relationships-and-junction-tables
Thank you, Stephen.
I will attempt the junction table approach with the Many-to-many relationship tomorrow.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.