Table structure for voting app I have an app where a user votes between two local profiles on which one is better. I want to ensure that the same user cannot vote more than once between the same two profiles (say the user votes on two different days or something), but I'm not sure what the most efficient way is to do this.

A simple solution is to have a table with 3 fields: voter (the user #), winner (the profile # who won), and loser (the profile # who lost). not necessarily gonna use those names, but I do want to use the data on who won/lost. 

Is it horribly inefficient and stupid to send a request for every new matchup to search that table to see if the voter/votees have already been processed? If not, what are my options? Is it really that huge of a deal? Or should I instead allow repeat matchups and simply update the table fields accordingly if the voter's choice changes?
Here's how I would model the tables for that requirement (note the table and column names can be changed for whatever is appropriate for your application):



In this model, the idea of a "Profile" and "User" is contained in the same entity, "User". The idea of a single vote for one of two user candidates is contained in the entity "Vote". If you want to restrict a User to one Vote per set of two users, then you can add a unique index in Vote for idUser, idUserCandidate1, and idUserCandidate2.