[eluser]jjmax[/eluser]
Hi folks,
I'm building a Dailyburn clone as a side project, for myself and hopefully the students at my school.
I've run into a bit of a problem though and hope someone can give me advice.
In my MySQL DB I've created a table for exercise routines called exercise_routines, and one for exercises called.... exercises.
Now a user will be able to create a routine, say 'Morning Exercises' and then add exercises to it.
They'll also have the ability to add sets and reps for each exercise, and then log their progress.
My problem is this.
Say I have 100 users and then they have on average 2 routines with 4 exercises in there.
That's 200 routines and 800 exercises in the DB associated with a individual users.
Not too bad.
But then they will perform sets of each exercise, so say an average of 3 sets = 2400 entries for sets on the db.
Each of these sets when performed will need to have the rep count recorded for them and logged.
I'm thinking the log table will grow and grow over time and I'm trying to figure out the best way to design it.
The way I would have done it is:
Exercise Table
ID
Name
Description
Routine_ID (linked to ID of routine in exercise _routine table)
Rep table
ID
Set_Number (set 1/2/3)
Exercise_ID (Linked to ID of exercise in exercise_table)
Date_Time
Count
Even looking at this now I realise that each time an exercise gets logged then there may be three additional records added to exercise_table.
I thought maybe I could try and store the reps log as some kind of delimited list in a single field but the advice on other sites says that this is bad form.
Can anyone point me in the right direction on this one please?
I know the user number is small, but that's only for now. I want to make the app robust and maybe make it live and put it on my portfolio.
Thanks in advance.
All the best,
John
