Optimal design for a large database
This is a classic situation where you use a "joining table".

You will need three tables.

Person
Skill
Person_Skill


(note that table names are singular - this is a preference of
 mine, not a rule).

Person
ID integer PRIMARY KEY
&lt;other person details - name, address, phone &amp;c.&gt;
KEY name (and possibly phone?)

Skill
ID integer PRIMARY KEY
&lt;other skill details - name, description, necessary qualification &amp;c.&gt;
KEY name (maybe not even necessary if there are only 50 skills?)    

Person_Skill
Person_ID integer FOREIGN KEY REFERENCES Person(ID)
Skill_ID integer FOREIGN KEY REFERENCES Skill(ID)
Unique Index on (Person_ID, Skill_ID) (to avoid duplicates)
KEY Skill_ID


This way you don't store the skill name, description &amp;c. for every person who has that skill, but just once and then refer to it in the Person_Skill table by its ID - this reduces space and memory requirements and is less error prone (you only store the Skill datum once - one of the core features of an RDBMS under Codd's rules).

That is the way I would do this.