Create a database with multiple values to one key - mysql

Question

I looking at trying to create a database that has keys with multiple values.
For example the key would be "benchpress" and the values would be "chest", "deltoid", "shoulder" .
I would have a bunch of these keys and then want to search the values and return all of the keys that contain what I was searching for. for example if I searched for chest I would get benchpress and other exercises that had that value.
I was wondering if this is possible and what the best way to do this is. I assume that I will have to use MySql for this.
Thanks!

Answer 1

You're probably going to want three tables to do this. One to hold all of your exercises, one to hold all of your muscles, and one to relate exercises to their respective muscles. You can then query the third table to figure out what muscles any one exercise targets using a JOIN statement.
The benefit of having three tables versus two is that each exercise definition and muscle definition is independent, so any exercise can target multiple muscles and any muscle can be targeted by multiple exercises.
Schema:
table exercise
id (int255) | exerciseName (varchar255)
table muscles
id (int255) | muscleName (varchar255)
table exerciseTargets
exerciseId (int255) | muscleId (int255)
Keys:
exercise.id: primary
exercise.name: unique
muscles.id: primary
muscles.name: unique
exerciseTargets.exerciseId: foreign key on exercise.id
exerciseTargets.muscleId: foreign key on muscle.id
Example query:
SELECT muscleName FROM muscles INNER JOIN exerciseTargets ON exerciseTargets.muscleId = muscles.id WHERE exerciseTargets.exerciseId = :exerciseId;
(where :exerciseId is the ID of an exercise.)

Answer 2

One way to do this in MySql would be to have two separate tables -- one for "exercise" and one for the affected muscle groups. These would be joined by a shared "key" (MuscleID). To add a new exercise to a muscle group, you'd just add it to the Exercise table with the correct "MuscleID".
For example:
create table Exercise (MuscleID int, exercise varchar(50));
insert into Exercise values (1, "benchpress"),(2, "leg press");
create table Muscles (MuscleID int, muscles varchar(50));
insert into Muscles values (1, "chest"),(1, "deltoid"),(1, "shoulder"),(2, "thigh")
select *
from Exercise as E
inner join Muscles as M on M.MuscleID = E.MuscleID
where E.exercise = "benchpress"
Demo: http://sqlfiddle.com/#!2/19c9c/1
However, this might not be a flexible enough system for you. The answer by #matt617 would most likely be a better option for a more comprehensive setup, but if you're doing something simple, this might work for you.

Answer 3

I would suggest looking into something more like an Ontology or a generic Graph Dataset.
An ontology formally represents knowledge as a set of concepts within a domain, using a shared vocabulary to denote the types, properties and interrelationships of those concepts. Whereas a Graph is a more free form notion of relationships (like a social network). All ontologies are in essence a graph but not all graphs are ontologies.
An VERY overly example of an RDF using the N3 format (which is the most common format for software ontologies) would be:
#prefix : http://www.example.org/ .
:bicep a :muscle.
:tricep a :muscle .
:quadracep a :muscle
then you would have a separate RDF for exercises
#prefix : http://www.example.org/ .
:benchpress a :exercise.
then you can start mapping them together:
#prefix : http://www.example.org/ .
:benchpress :uses :bicep :pectorals
There is also an XML format. For more information a good sample site is here: http://www.rdfabout.com/quickintro.xpd
Infact I wouldn't be surprised if RDFs for muscle groups exist in the open domain I just haven't looked much for them.
If you are more of a programmer at heart than an information scientist type then Neo4J is a great Graph DB that lets you implement graphs without doing full ontologies. It uses a pretty handy query languge called Cypher which describes the relationships http://www.neo4j.org/learn/cypher
I am sure you could make a MySQL DB that was sufficient for your needs but it will be very hard to maintain depending on the long term of your application.