Page 1 of 1
IP Logging/Voting
Posted: Tue Sep 04, 2007 3:31 pm
by GloriousEremite
Some blog software I'm using has a plugin for rating entries, but all it does to avoid people voting multiple times is check if a cookie is present. I wanted to implement an IP check to see if the person has already voted on a specific item, but I'm unsure how I should store the information in the database (using MySQL by the way)
I guess I could keep a table of IP addresses, and store a list of items for which they have voted in each row, but how would you store that list? Should I just have a column for each blog entry? Would that be inefficient since most users probably wouldn't vote on every entry, and I'd have to update the table every time a new item was posted?
Posted: Tue Sep 04, 2007 6:42 pm
by califdon
What about different users from behind the same proxy? You probably don't want to limit them. What about the same dialup user who gets a different IP address every time he/she logs in?
But as to how to store the data if you decide to collect it, I would recommend the following schema:
tblRatings:
UserID
IP
Item_ID
RatingDate
Small records, easy to search for IP and Item_ID, and you could identify the user and date.
Posted: Tue Sep 04, 2007 10:29 pm
by GloriousEremite
Well, I was thinking of allowing "anonymous" (i.e., the visitor doesn't have to log in) voting, in which case I can't think of any other way to have some sort of protection (and the issues you mentioned probably wouldn't amount to a huge problem). Maybe I'll just force visitors to have an account to vote.
I guess your schema will work alright, it just seems redundant (I'll have to store UserID or IP multiple times if someone votes on multiple articles). It is simple, though--as opposed to somehow storing an array of ItemIDs for each UserID.
Posted: Wed Sep 05, 2007 1:01 pm
by califdon
GloriousEremite wrote:Well, I was thinking of allowing "anonymous" (i.e., the visitor doesn't have to log in) voting, in which case I can't think of any other way to have some sort of protection (and the issues you mentioned probably wouldn't amount to a huge problem). Maybe I'll just force visitors to have an account to vote.
If those issues aren't important in your application, then I would think using IP's would work.
I guess your schema will work alright, it just seems redundant (I'll have to store UserID or IP multiple times if someone votes on multiple articles). It is simple, though--as opposed to somehow storing an array of ItemIDs for each UserID.
There's always redundancy if you need the data. Every foreign key is redundant, in a sense, but it's absolutely necessary in order to associate rows in different tables. These days, storage is rarely an issue. Anyway, good luck with it.