Forum Moderators: open

Message Too Old, No Replies

Multi Column Tables

Multi Column Tables

         

typomaniac

5:49 pm on Jun 20, 2015 (gmt 0)

10+ Year Member Top Contributors Of The Month



I need to put something together using mysql where, awards(hundreds) and badges(also in the hundreds) need to be listed and this is where I'm not sure which way to go---the awards and badges are military in nature and I need to be able to go through the db and figure how many recipients of each medal & badge exist and on the other hand, who has them. In one sense, I need to be able to print out stats but on the other side, need to be able to display a profile of each person and what awards&badges they have been awarded. I'm not real experienced at this and have read posts which say to avoid to many columns in a table, but the first thing that came to me was a "many column" table with each award as a column name and a default entry of 0 and after that an integer indicating how many times a person many have won a certain award using an id column to identify the person. I also thought to break up the awards into categories to make the tables smaller (less columns). Any input & direction much appreciated.
btw..if it makes any difference I'll be using perl for scripting.

topr8

11:27 pm on Jun 20, 2015 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



personally for this i'd use 3 tables.
using a simple relational database model.

table_personnel ... unique id for each person, then columns for whatever personal details you are keeping: first name, last name, dob etc etc

table_awards_and_badges ... list them all in this table, unique id column, name of badge/award, description, type (eg 1=award, 2=badge)
(you could have 2 tables, one for awards and one for badges)

and your third table - the connecting table ...something like
personnel_to_awards with columns like personnel_ref (references the id column of the personnel table), badge_or_award_ref (references the id column of the awards and badges table), date_issued (date award/badge given), notes (any notes or observations about this specific issuing) etc etc

the reason i'd do this is that new badges/awards are easy to enter into the database. (you don't need to add a column to a table, eg change the table structure, just enter a new row)
thus queries would never have to be rewritten to account for new columns.
it would also be the most compact way of doing things, your way would have lots of empty columns.

you could pull data from the database with very simple joins - so your queries would be simple to write.

LifeinAsia

4:51 pm on Jun 21, 2015 (gmt 0)

WebmasterWorld Administrator 10+ Year Member Top Contributors Of The Month



Definitely go with topr8's suggestion- you don't want to have to rewrite your queries every time you add a new award/badge.

Also, if you're not going to take advantage of the underlying purpose/power of a relational database, what's the purpose of using it in the first place?

typomaniac

4:10 am on Jun 22, 2015 (gmt 0)

10+ Year Member Top Contributors Of The Month



Thanx, it took a while to sink in but I think I have it now. Hopefully that will take care of things.