A comprehensive fitness tracker database schema designed for mobile health and workout applications. Includes user profiles, workout sessions with duration and calories tracking, an exercise library, many-to-many workout-exercise relationships with sets/reps/weight data, and personal fitness goals with progress tracking. Ideal for apps like Strava, Nike Run Club, or custom fitness solutions.
exercises is a shared library and workout_exercises is one person doing one of them. The library row knows the muscle group and the difficulty; the link row knows the sets, the reps and the weight lifted that day. Separating them is what makes progress on a single lift a query rather than a search through free text.
body_metrics is a time series, not a profile. users carries height and a current weight for convenience, while every measurement ever taken lives as its own row with a recorded_at — because the whole point of tracking is the shape of the line, not the last value.
Calories appear twice with different meanings. workout_types.calories_per_minute is an estimate used to fill in a number; workouts.calories_burned is what was recorded for that session. The stored value survives the estimate being revised, which is what keeps last year's totals stable.
Letting someone type bench press each time is faster to build and makes every progress chart impossible — three spellings become three exercises. A shared table means sets and weights accumulate against one row, muscle-group filtering works, and the cost is that an exercise nobody has added yet cannot be logged until the library grows.
A goal like run 100km this month could be computed from workouts on every view. Storing the running value makes the goal screen one read and lets goals exist that the app cannot derive at all — a target weight, a habit, something logged elsewhere. The cost is that it must be updated as activity lands, and a corrected workout leaves it stale until recomputed.
Each food is its own row with a meal_type and a timestamp, so a day is assembled by date rather than by a meals table. That keeps logging a single insert and makes a daily total a simple sum. What it gives up is the meal as an object — you cannot name, save or repeat yesterday's lunch without matching rows by time and type.
users.weight_kg is the convenient current value; body_metrics is the history. Keeping only the profile column would make the app a scale rather than a tracker. Both means a write updates two places, with the time series as the authoritative record the profile can always be restored from.