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?
IP Logging/Voting
Moderator: General Moderators
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.
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.
-
GloriousEremite
- Forum Newbie
- Posts: 13
- Joined: Tue Aug 14, 2007 1:00 pm
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.
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.
If those issues aren't important in your application, then I would think using IP's would work.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.
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.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.