Is a "Day" table a good idea in this case?

user_12747084 0
Viewed 60

So, a friend and I are designing a Workout Tracker application as a side project. In this application, you can have Programs which include a group of Workouts which have a bunch of Sets. Let's suppose that you only train once per day and not always do you want to train a specific Workout, instead, you'd want to add the exercises while training.
So, we have thought of creating a table named Day which would have the following attributes:

  • ID - as primary key (probably the date)
  • WorkoutID - Nullable, if the date does not have any workout.

Also, there would be an auxiliar table named DayExercices which would hold all the exercises done in that day.

These scheme would allow us to link a Workout (which would bring us to it's exercises in the table WorkoutExercices) and, if the user would want to add any other exercise on that day it would be possible since it would be added to the DayExercices.

However, would this be considered good practice? Should we change the database scheme?

This is the current database scheme.

CurrentDatabaseScheme

sql
1 Answers

So basically from what I've understood is that an exercise can indeed happen more than once a day so you would need something like this:

ID, Day, ExerciseID

The Id will be the primary key cause you can have multiple same pairs of Day, ExerciseID.

Also I took a quick look to your schema and it seems to me like you have a circle there. I would suggest throwing away the table WorkoutMuscles. A workout is a set of exercises and those exercises actually train your muscles. For example imagine that you add a new exercise under a workout, this means that you would need to also update the WorkoutMuscles. Furthermore I suggest renaming the WorkoutExercises table to Exercises. The tables should be named us their entities not the relation they have.

You can create views if you want to retrieve the information more easily.

user_98224010
Related