I wasn’t sure entirely how to word this for the question, so I’ll explain what I’m thinking. I have previous experience designing databases but really haven’t decided how I want to implement this or run across this before. I’ll explain what I’m thinking as a way of showing I have thought this out…
I’m creating a database that will store information of a user for things like a resume (this is a side project for a bunch of college kids). The issue I’m coming across is how to deal with storing a large amount of things like technical skills, perhaps of the order of 20+ per user as well as their proficiency
Idea one: One huge table with columns of TechSkill1 -> 20. Along with their proficiency. Use the user ID as the FK to relate to all of these.
Pros: Easiest implement, easiest on the front end.
Cons: limited to 20 skills, lots of potential for nulls, excessive size
Idea two: Table of a large text input with all skills in one text object delimited by some character like a comma or a |. Another column for proficiencies delimited the same way. Again, USERID as a FK.
Pros: easy to implement, small table size, easy on the front end to get information
Cons: possibility of wasting a lot of empty space, need to do more coding on the front end before the store and then upon retrieving.
Idea Three: Small table with the column of skill and proficiency. Then create multiple rows to relate to each USERID
Pros: smallest table and cleanest. Saves the most space
Cons: front end implementation will be interesting as in, how to deal with multiple fields for an unlimited amount of entries (not my stuff, but I don’t want to create too many issues for the front end guys)
Those were my three ideas, I’m not entirely sure what would be best so… I’m asking you guys. All advice would be greatly appreciated.
Thanks!
-Jabsy
best way to implement this on database level is to create 4 tables:
This way you won’t waste space and your architecture will be more scalable and maintanable.
You addressed problem of front end implementation. The best way remedy this is create database View (which DB engine u use?) with more “front end friendly” view of data. It’s not a good idea to denormalize your schema to ease up front end development, mainly because data manipulations are the most fragile operations in information systems. Keep your schema clean and you will save yourself a lot of trouble in the future when scaling up and adding new features.