Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
CODE PROJECT For Those Who Code
  • Home
  • Articles
  • FAQ
Community
  1. Home
  2. Database & SysAdmin
  3. Database
  4. exercize database schema: need advice

exercize database schema: need advice

Scheduled Pinned Locked Moved Database
databasegame-devxmltutorialquestion
1 Posts 1 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • M Offline
    M Offline
    mbrownphysics
    wrote on last edited by
    #1

    Hi. I came to software development primarily through physics. I have a fair amount of experience, but not much of it has to do with databases. I'm building an exercise database for a web site, and I need some suggestions about schema. The idea is to relate exercises to muscles. This, however, is overly simplistic. Any exercise can belong to a group of exercises, and there can be multiple variations of an exercise. For example, front squats and back squats are fundamentally different exercises, even though both are squats. Likewise, when doing a back squat, someone can go down until thighs are parallel, or go down until his rear is almost touching the ground. These are both back squats, but have quite different effects. My initial thought was to have a table for exercise groups, exercises, and exercise variations. Along the same lines I would have a table for a muscle group, and another for muscles. All would have mutually exclusive unique id's. This way, in a single relational table (many to many relationship), a given row could have one field containing a muscle or a muscle group, and another field can contain an exercise group, and exercise, or an exercise variation. Although this would be well normalised, I'm thinking that once I carry this on to a few other things (like heads, joints, etc) this could result in a lot of small tables. It is also somewhat limiting. What if I want a variation of a variation, for example? My second idea was that muscles and muscle groups would be in one table. There would be a field called 'group'. 'vastus lateralis' would be related to 'quadriceps'. For 'quadriceps', this field would be blank. Likewise, in the exercise table, I would include exercises, exercise groups, and exercise variations. Then under the 'variation of' field, 'parallel squat' would be related to 'back squat', 'back squat' would be related to 'squat', and for 'squat' the field would be empty. This seems to me to be a more flexible approach, and would probably be easier to maintain, but like I said, I do not have the benefit of experience on this. Can anyone give me advice on this? Thanks Matt Brown

    1 Reply Last reply
    0
    Reply
    • Reply as topic
    Log in to reply
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes


    • Login

    • Don't have an account? Register

    • Login or register to search.
    • First post
      Last post
    0
    • Categories
    • Recent
    • Tags
    • Popular
    • World
    • Users
    • Groups