Jessica Posted February 28, 2007 Share Posted February 28, 2007 I have a table which needs to store "points" for 8 groups. It gets a new entry weekly, but the points are updated many times daily. There may be more groups added in the future, but I would know about it first, and have the change to add a new column to the table. This is how it currently looks: CREATE TABLE `weeklyPoints` ( `weekID` int(10) unsigned NOT NULL auto_increment, `start` int(11) NOT NULL default '0', `end` int(11) NOT NULL default '0', `winner` int(11) NOT NULL default '0', `genre_1` int(11) NOT NULL default '0', `genre_2` int(11) NOT NULL default '0', `genre_3` int(11) NOT NULL default '0', `genre_4` int(11) NOT NULL default '0', `genre_5` int(11) NOT NULL default '0', `genre_6` int(11) NOT NULL default '0', `genre_7` int(11) NOT NULL default '0', `genre_8` int(11) NOT NULL default '0', PRIMARY KEY (`weekID`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ; I was trying to decide between that, or adding yet another table to store just genreID and points, so that when I add a new genre I don't have to update the table. Not sure if it's reasonable, or worth it. Thoughts? Quote Link to comment Share on other sites More sharing options...
roopurt18 Posted February 28, 2007 Share Posted February 28, 2007 I'd add that second table. Build a scalable solution now and you can forget about it later. One of the tables from our <shudder> dbase server application at work has 100 additional columns, Plan1 through Plan50 and then sqft1 through sqft50. I look at it and honestly can't believe anyone ever set it up that way to begin with. Quote Link to comment Share on other sites More sharing options...
designationlocutus Posted February 28, 2007 Share Posted February 28, 2007 Hmm you may need two tables. The genre entries suggest that you have a many-to-many relationship between weeklyPoints and genre. A single weekly point entry can have one to many genres while a single genre can be included on 1 or more week You could also give each genre a name too. For example: weeklypoints ========== id start end winner (is winner a foreign key to a person table?) weeklypoints_genre =============== id weeklypoints_id genre_id genre ==== id title Quote Link to comment Share on other sites More sharing options...
Jessica Posted February 28, 2007 Author Share Posted February 28, 2007 No, winner is a genre, 1-8. Normally I would have done it the way you guys are suggesting, I was just thinking this time that it might be easier this way. roopurt - I see what you mean, it makes sense for the first time when there's only 5 groups, but then they keep getting added and added. Thanks guys, I'll change it now. Quote Link to comment Share on other sites More sharing options...
Barand Posted March 6, 2007 Share Posted March 6, 2007 NEVER design tables that will mean changing that table design to accomodate extra recurring fields. Normalize it with the second table. If you don't then not only do you need to keep altering the table but also need to change your code too with every table change. (Depends on the terms of your maintenance contract I suppose - it could provide steady income ) Quote Link to comment Share on other sites More sharing options...
Jenk Posted March 7, 2007 Share Posted March 7, 2007 (Depends on the terms of your maintenance contract I suppose - it could provide steady income ) but could also lose you income due to all this "extra" expense. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.