Hi, Your solution is a good way (I use the same system for user contributions vote).. The size of the DB is not a problem... You can add an history table if you work month by month. Like this, your 'voting' table will only have current month value, and the history table will get results for each month.. No?
Regards, P.E. Baroiller "Monty" <[EMAIL PROTECTED]> a écrit dans le message de news: [EMAIL PROTECTED] > I'm writing a survey app in PHP (4.2.2) that will allow people to view a set > of photos and then rate each photo from 1-5 using a little dropdown under > each photo. When they are done choosing their ratings, they click on SUBMIT > to register all their votes at once. > > I thought the best way to record votes was to create a record for each > member and each photo they voted on in MySQL. So, for example, if someone > rates 9 photos, there will be 9 records created in the voting DB structured > something like this: > > item_id // ID number of the photo being rated. > member_id // ID of the member making the vote. > date // Date vote made. > rating // 1-5 > > While this system offers a lot of flexibility in calculating votes, I'm > worried that the DB will become full fast with records because of the number > of records created for each member when they vote. If there are 10 photos > and 2,000 people rate those photos, that will create 20,000 new records in > the DB for that one poll alone. > > So, I'm wondering if anyone has any suggestions for better ways to store > votes like this without created so many DB records. I want to be able to > calculate total votes for each photo as well as prevent members that have > already voted from voting again. > > Any suggestions would be appreciated! > > Monty > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
