Proper way to organize fields--repeating or other?

[ScoobyDoobyDude]

Hi everyone. After extensive searching I have not been able to find a conclusive answer to my question--your expertise would be greatly appreciated.

Although I have fairly advanced skill in computers, I am a complete novice at FileMaker. I know enough about relational databases to "get by" but still have much to learn in order to be autonomous in my projects. So, that being said, here is my question:

I would like to build a "workout plan" solution, to be used by both trainers and their clients. The trainer would input a workout plan for each client, including the name of the exercise, the number of sets, and the number of reps per set. This would be cross-referenced to a separate table or database of the actual exercises, so that if the customer has a question about how to perform the exercise they can obtain that information. I would like to be able to print both blank workout pages for people to take to the gym, and hard copies of the same sheet that have the data electronically filled in.

My question regards the structure of the database... because different exercises will have a different amount of sets and reps, I thought it might be wise to use repeating fields for these items [such as "workout_numsets" with up to 5 repetitions]... this way, if some exercises have 3 sets and some have 4, there would be room for that data.

I have been cautioned before about using repeating fields, but I'm not sure how else to put something like this together. My main concern is when it comes time to print the sheets--I want to be able to print a "grid" showing the planned workout on the left in a column, and the actual work performed for each session in columns going from left to right. I'm not sure how to get FileMaker to align everything so that it automatically gives enough table cells for the sets when not only printed, but also displayed.

Please let me know if I am being unclear--I have no example file yet to display, as I want to make sure I have the right kind of structure in mind before actually designing the database.

Thanks in advance for your help!

Brandon

[Fenton]

I'm kind of not seeing where you'd even need repeating fields.

name of the exercise, the number of sets, and the number of reps per set.

This just looks like 3 fields to me. Unless you're going to say something specific to each set or rep.

It is certainly true that the Client|session|exercises would be its own table, like an "exercises plan" for that client, a template for each session performed. (Session being something like days of week they're supposed to come in.)

blank workout pages for people to take to the gym

I'm gathering from the "blank" above that clients are going to record details of each session, including exercises performed, incl. sets and reps. Question: Can they enter an excercise that is NOT on their plan? It's not a big problem, but it means you'd need a way to add this in your computerized data entry (as they'd just writing it in on paper).

The Client|date|time would then be its own table, used when when they come in. Imported from their plan template, printed as blank, then entered into FileMaker after a session.

The Client|date|time|exercise would be its own table, for the multiple exercises performed, 1 record per exercise. This would be main data entry table, filled in (or checked off) after each exercise. But the number of sets and number of reps per set would just be a field each. Unless you're recording exactly how many reps they did per each set; but wouldn't they always do all of them (or be punished :-).

If they didn't, and you wanted to record that fact, then you could use repeating fields for sets and reps at this point I think. Or another table with a record for each set. It really doesn't make much difference.

You expressed concern about layout. But both repeating fields AND portals can be either vertical or horizontal now. It's a little more trouble for portals, but not bad.

I say things like "Client|date|time|exercise" for that last table, but in reality the structure would be tied together with IDs, not words. You will have "reference" tables for the Clients and Exercises. The Date and Time would already be in the Client|Date|Time (session) table. So that last table would only need the ID of the Session table and Exercise ID to identify a record.

[ScoobyDoobyDude]

Fenton --

Thanks for your reply. Actually, you expressed my main concern very well -- when I go to the gym, I often "max out" on repetitions in order to continually increase my weight. Although my planned workout may be "10, 8, 6, 6," I often will have something more along the lines of "10,8,7,5" or something similar. In addition to merely tracking workouts as I would in a spreadsheet, I want to make the solution more modular, and have it not only connect the name of the exercise with the instructions, but also to create "ready-to-use" workout plans without the need for manually adjusting column width, editing text, etc.

So, as you mentioned, it is crucial that I be able to report differences in the amount of reps performed per set, and the amount of sets for each exercise. Based on that, I want to make sure when I put together my layout, that the workout sheet automatically knows how much space to put between each column. For example, if I have one exercise that has four sets planned, and one that has six sets, there will need to be two extra "blank spaces" between the last set on the exercise that requires four sets, and the first set on the following day:

Exercise Day 1 Day 2

Bench 4x12 X X X [color:green]X X X X X

Cable 3x12 X X [color:green]X X X X

Machine 5x12 X X X X [color:green]X X X X X X

Does that make sense?

Actually, I went to your web site and noticed the screenshots for the scheduling solution you had on there. Very impressive--I have been trying to figure out the logic for such a solution for some time now and have not yet found any instructions for putting one together.

Somehow I think the two concepts may be loosely related, at least in terms of layouts. But nevertheless, I would love to know how you were able to put your scheduling solution together.

Thanks again for the info!

P.S. -- Okay, it looks like my extra spaces got taken out by the editor program on the forum. So instead I made the X's where I would need extra space the color green. You can see that for the bench I would need one extra "cell" in between record items, and for the cable I would need two extra "cells."

Edited June 10, 2007 by Guest

[Fenton]

From what I see above, you want a kind of schedular, which displays the exercises for each of a series of days, as a checkbox (or something). Is that what each checkbox is for, that day?

There's more than one way to do that. A big question is how many days (a week?). Because if it's only a few, then I think I'd use global fields for the days, with a self-relationship for each. That would let you display the data as you said.

That's much the same principle as my scheduling "time grid" solution. Though it had a bit more going on.

The data file in either case is fairly simple and what you'd expect. The complexity comes from getting it to display like a schedule. But it's not rocket science (I always wonder, what do rocket scientists say? :-)