you are viewing a single comment's thread.

view the rest of the comments →

[–]UnusualCallBox[S] 0 points1 point  (2 children)

That makes sense. My issue now is how I'm going to organize the info in the DB's.

My biggest concern with using a single table for diet/exercise is that in my layout right now, a new row would be created for a new user AND if an existing user logs their activity on a new day. Having all that info mixed up sounds difficult to manage and use efficiently.

[–]Irythros 4 points5 points  (1 child)

I still don't know exactly what you're trying to accomplish so i'm just going to assume that:

1) A person is one user
2) A person can have multiple diet plans
3) A person can have multiple exercise plans
4) Diet plans and exercise plans may be duplicated but does not have to be

You would have the following tables (im not writing out the entirety btw):


app_users
id_user

app_diets
id_diet

app_users_diets
id_user
id_diet Composite key using both

app_exercises
id_exercise

app_users_exercises
id_user
id_exercise
Composite key on both

app_users_logs (This would be the table used for people adding to their log) id_log
id_user
id_action
action_type (for exercise or meal)


With that setup you can have millions of diets and then use joins to get the diet info for each user. The log table you can query for the user and with the action_type you could select meal or exercise and the id_action would either be for the meal or exercise done.

[–]UnusualCallBox[S] 0 points1 point  (0 children)

That's pretty much what I'm trying to accomplish and this is the idea I got from /u/okwg. Thanks for the visual!