Как было сказано в комментариях, «лучшая практика» предполагает, что существует только один лучший способ сделать что-то, а это не так. Практически во всех решениях для разработки программного обеспечения вам приходится торговать беспорядочно, непредсказуемым образом, который почти всегда зависит от контекста.
Если я понимаю ваш вопрос, у вашей проблемной области есть понятие «пользователь», который создает ноль или более тренировок, и каждая тренировка имеет одно или несколько упражнений, и последовательность, в которой выполняется это упражнение, является Важный атрибут отношений между тренировками и упражнениями.
Обычный способ хранения атрибутов отношения «многие ко многим» - это дополнительные столбцы в присоединяемой таблице.
Нормализованный способ хранения этого будет выглядеть примерно так:
user
-----
user_id
name
...
Workout
-----
workout_id
name
....
Exercise
------
exercise_id
name
....
workout_exercise
----------
workout_id
exercise_id
sequence -- this is how you capture the sequence of exercises within a workout
... -- there may be other attributes, e.g. number of repetitions, minimum duration, recommended rest period
user_workout
--------
user_id
workout_id
.... -- there may be other attributes, e.g. "active", "start date", "rating"
С точки зрения компромиссов, я бы ожидал, что это масштабируется до сотен миллионов строк на аппаратном обеспечении без существенных проблем. Запросы могут быть достаточно сложными - вы будете объединять 4 таблицы - но это то, для чего предназначены базы данных. Модель данных описывает (что я понимаю) проблемную область, используя отдельные сущности и т. Д.