Skip to main content

I’m trying to see if I can use Airtable to set up a gym log and then get everyone at my fight club to use it. Here’s my use case(or what I think it should look like):

Table 1: Exercises - Squats, Bench Press, Sit-ups, Run, Boxing, Muay thai
Table 2: Session Type - Strength, Cardio, Abs, Boxing, Muay Thai
Table 3: Log - This is a log of every session.

With all this setup, at the end of a session, I should create a new “Log” entry and log my session. The current setup looks like this:

This is all good but the problem I’m having is with the Exercises column in the Log Table. Each exercise has Sets and Reps. When I add an exercise and edit those fields, all other instances of that exercise updates :cry: . What I want is a way to add exercises to multiple “Log” entries and have the Sets and Reps fields unique to that entry. So the sets and reps I log for squats on the 11th of May could be different for that of 12th May. I cant do this in the join table because there will be multiple exercises per Log entry.

I hope this makes sense. I’ll appreciate any help.

If anyone wants to have a play with it, here is the link to the table:

Airtable: Organize anything you can imagine

Airtable works like a spreadsheet but gives you the power of a database to organize anything. Sign up for free.

Cheers,

Hi fayl,
Instead of pulling the exercises from a table, why not make it a Single select? Then the sets and reps values will be unique to that record.

Then you can remove the exercises table all together.

Bill

Hi fayl,
Instead of pulling the exercises from a table, why not make it a Single select? Then the sets and reps values will be unique to that record.

Then you can remove the exercises table all together.

Bill


@William_Coron Did you mean Multiple select? I tried that but the problem with that is when I convert that column to multi-select, each option doesn’t have fields. It becomes more like a label than an entity with attributes.

@fayl, yes, it will make it more of a tag. Then you can move the attributes like sets and reps, which change, to be part of the log table so they don’t change another person’s sets and reps. Even if you kept exercise as a table with attributes, the sets and reps should belong to the log record, not the exercise record.

@William_Coron Did you mean Multiple select? I tried that but the problem with that is when I convert that column to multi-select, each option doesn’t have fields. It becomes more like a label than an entity with attributes.


Here’s how I’d do it.

I’ve changed the name of your [Log] table to [Session] and made it your main table, with everything else descending from it.

Each [Session] record links to one or more [Exercise] records. (Increasing line height on [Session] to ‘extra-tall’ gives more visibility to the exercises done during each session.) An [Exercise] record consists of the {Exercise} type and the number of {Sets} and {Reps}.

In this case, I’ve changed {Exercise} to a single-select field. However, I can think of reasons why you might wish to keep it a linked record; should that be the case, simply change {Exercise} to a linked-record field pointed at the [ExerciseType] table.

Note: If you go with {Exercise} as a linked record, you should disable links to multiple records. Each {Exercise} record should track sets and reps for a single exercise performed during a specific session. That keeps you from inadvertently stepping on old data.

Conversely, I’ve kept {Session::SessionType} (that is, the {SessionType} field in the [Session] table) as a linked record, but it could just as easily be made a multi-select field.

Clearly, if you decide to track multiple individuals in a single base, you’ll need to create a [Members] table. Each [Members] record will link to multiple [Sessions] records. (You’ll probably want to change the {Name} formulas for the [Session] and [Exercise] tables to include {Member::Name}, looked up from the linked record source.)

P.S. I may have stepped on some of your original base :frowning: , stupidly. The safest way to share bases with such potentially chowder-headed collaborators as I is to post read-only shares with copying permitted; that way, any fiddling about that occurs with the base takes place only within our copies, not your original.

Here’s how I’d do it.

I’ve changed the name of your [Log] table to [Session] and made it your main table, with everything else descending from it.

Each [Session] record links to one or more [Exercise] records. (Increasing line height on [Session] to ‘extra-tall’ gives more visibility to the exercises done during each session.) An [Exercise] record consists of the {Exercise} type and the number of {Sets} and {Reps}.

In this case, I’ve changed {Exercise} to a single-select field. However, I can think of reasons why you might wish to keep it a linked record; should that be the case, simply change {Exercise} to a linked-record field pointed at the [ExerciseType] table.

Note: If you go with {Exercise} as a linked record, you should disable links to multiple records. Each {Exercise} record should track sets and reps for a single exercise performed during a specific session. That keeps you from inadvertently stepping on old data.

Conversely, I’ve kept {Session::SessionType} (that is, the {SessionType} field in the [Session] table) as a linked record, but it could just as easily be made a multi-select field.

Clearly, if you decide to track multiple individuals in a single base, you’ll need to create a [Members] table. Each [Members] record will link to multiple [Sessions] records. (You’ll probably want to change the {Name} formulas for the [Session] and [Exercise] tables to include {Member::Name}, looked up from the linked record source.)

P.S. I may have stepped on some of your original base :frowning: , stupidly. The safest way to share bases with such potentially chowder-headed collaborators as I is to post read-only shares with copying permitted; that way, any fiddling about that occurs with the base takes place only within our copies, not your original.


Wow this is really amazing. Thanks a lot for taking the time to help, I really appreciate it. This was a test project to see if I can use Airtable for anything I do and I feel like I can probably use it for everything!

I’m going to take some time to study this. Out of curiosity, do you know any public bases with reasonable complexity I can look at?

Wow this is really amazing. Thanks a lot for taking the time to help, I really appreciate it. This was a test project to see if I can use Airtable for anything I do and I feel like I can probably use it for everything!

I’m going to take some time to study this. Out of curiosity, do you know any public bases with reasonable complexity I can look at?


I’d suggest grazing through Airtable Universe and/or the Template Collection. If you don’t mind a base with unreasonable complexity, there’s always my Wardrobe Manager.

Terms & ConditionsAccessibility statement