Unanswered: Best schema for like/dislike functionality
I'm building a db that will hold comments to a website. Each comment will have a like/dislike button. I can come up with 100 ways of storing the like/dislike information, i'm just not sure what makes the best business sense.
I know that I don't want the same ip address liking or disliking the same thing multiple times...
should I just store all the likes/dislikes in one table, checking before insert if they already interacted with it. if they liked it before, and are now disliking it... do i just update the record to dislike for that ip?
what's best practice? incorporate multiple tables? seems silly...
Well, I probably would not base likes and dislikes on IP addresses. Most folks get IP addresses automatically from a DHCP server, so each person's address (and their likes and dislikes) might shift from one week to the next.
Outside of that, a primary key on commentid and IPaddress should get you pretty close to what you want.
i know it's not 100% sound using the ip, but it would prevent that person from clicking multiple times in succession at least. I'm not going to incorporate a login/username... so that's out of the question.
i guess most places that allow voting stuff do so based on your account/login.
We can at least agree that most solutions are not bullet-proof.
I would suggest having your web pages accepting a SessionID parameter. Whenever a request is made without a session ID, a new random SessionID is created. Have the vote require a valid SessionID, and enforce only one vote on a specific item for each SessionID.