Your solution is a good way (I use the same system for user contributions
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..

P.E. Baroiller

"Monty" <[EMAIL PROTECTED]> a écrit dans le message de news:
> I'm writing a survey app in PHP (4.2.2) that will allow people to view a
> 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
> 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
> 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
> 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

Reply via email to