Question when designing a database
Splitting up the tables into different activities sounds like a much better plan than trying to shoe-horn 7 different activities into 1 table. 
Different objects belong in different tables - rule of thumb - better to have many smaller tables that are "thin" - i.e. fewer fields than 1 megatable which is "fat" (i.e. many fields, many of which will have to be NULL). These sorts of tables are unwieldy and difficult to programme against.
Check this out to see what happens if this advice is ignored to the point of lunacy :-)


Finally, if this is your first database  project, try a prototype with a couple of activities and see how that goes. Better to make your mistakes on a small project than a big one (and you will make mistakes). 

Be sure to have a working, relatively complete, prototype before moving on to the full project.

Come back here if you get stuck on more specific issues - your question is a bit "broad" for this forum. After successfully completing a prototype you should then be ready to move onto a bigger undertaking.