Skip to main content

Link to record with some fields unique per instance

F
  • fayi
  • New Participant
  • 2 replies

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 😢 . 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,

    6 replies

    W
    • William_Coron
    • Participating Frequently
    • 8 replies
    • May 13, 2018

    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

    F
    • fayi
    • Author
    • New Participant
    • 2 replies
    • May 13, 2018
    William_Coron wrote:

    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.

    W
    • William_Coron
    • Participating Frequently
    • 8 replies
    • May 14, 2018

    @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.

    W
    • W_Vann_Hall
    • Inspiring
    • 1386 replies
    • May 14, 2018
    fayi wrote:

    @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 😦 , 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.


    F
    1 person likes this
    • F
      fayi
    F
    • fayi
    • Author
    • New Participant
    • 2 replies
    • May 15, 2018
    W_Vann_Hall wrote:

    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 😦 , 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?

    W
    • W_Vann_Hall
    • Inspiring
    • 1386 replies
    • May 15, 2018
    fayi wrote:

    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.

    F
    1 person likes this
    • F
      fayi

    Reply


    Most helpful members this week

    Terms & Conditions