If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
|
#1
|
|||
|
|||
Lots of Fields or lots of records
DawnTreader wrote:
Hello All i have a table that as it is currently designed has a huge amount of fields, and as time goes on i am sure that the number of fields might change to include more. Dead giveaway. This structure is absolutely wrong. I once had to deal with tons of databases set up like this and it wasn't pretty. You would probably be better off with something like Person---(1,M)---Evaluation----(1,M)-----SkillRating----(M,1)----Skill---(M,1) ----SkillGroup SkillRating(EvaluationID, SkillID, Rating(0-5)) Most everything in your list is a *record* in the "Skill" table (like Electronics 1, Electronics 2, etc) You can pretty much tell your structure is wrong if... 1. you need to modify your table structure continually as you store new facts. 2. querying the database is a *nightmare* - for example, show me all of Person X's skills that are above 3. What SkillGroup are most of them in? You can't do it if you store the Skills in field *names*. Facts belong *in* the table (in a record), not *on* it (in a column name). -- Message posted via http://www.accessmonster.com |
Thread Tools | |
Display Modes | |
|
|