construct the table is with a series of "Yes/No" fields for each interest
Quite simply, no. Additions or deletions of activities (or any 'thing') that requires adding or no longer using a table field is the first indication that the db is not properly normalized.
At a minimum, you should have tblMembers, tblActivity (with all activities listed in one field) and then to make the 'connection' between a member and their chosen activities, a junction table (tblMemberAct). The junction table would have a field for the member id (tblMembers.MemberID as a foreign key in tblMemberAct and tblActivities.ActivityID as another foreign key in tblMemberAct. If John (id = 32) chose 5 activities, there would be 5 entries for ID 32 in tblMemberAct, something like
MembrID_FK |
ActID_FK |
32 |
2 |
32 |
5 |
32 |
8 |
32 |
12 |
32 |
15 |
If you want to track meeting attendance, that is another thing, requiring at least a table for meetings and their dates. There are options when designing a form for this besides check boxes, which I think would be a mistake. Yes you could use a multi-select combo to choose the activities, but I think a multi select listbox is a superior choice. Don't bother creating a form until you have the proper table setup and queries that retrieve data correctly or allow data input.
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.