Fitness Tracking App Data Model: Tables, Keys and Relationships

Lay out the database for a fitness app: the tables it needs, their keys, and how they relate to each other. ```hint Start from one logged workout Picture a single session a user records and list everything attached to it. Then ask what changes between a strength session and a run, and let that shape the tables. ``` ### Clarifying Questions - Which activities must the app record: gym workouts with sets, reps and weights, distance-based cardio such as runs and rides, or both? - Does data arrive only through manual entry, or also from phones and wearables that stream readings such as heart rate and GPS points? - Are goals, training plans or social features such as following friends in scope? - Is this the transactional database the app writes to, or a model for reporting and analytics? ### What a Strong Answer Covers - The core entities, with primary keys, foreign keys and the cardinality of each relationship - How the exercise catalog relates to what a user actually logged - How the model handles activities that record different measurements, and the trade-off of the chosen approach - How the design copes with high-volume device readings, and which indexes serve the main screens and product metrics - Time zones, units, duplicate device syncs and deletion of health data ### Follow-up Questions - How would the schema change to let a coach assign a multi-week training plan and track which sessions the user completed? - A watch sometimes uploads the same run twice, and some users also log that run by hand. How do you keep totals correct? - Which product metrics would you compute from these tables, and which belong in event analytics instead?