The site is a voting site for music artists. Each artist is saved in a database and they have a vote column. Each time a user clicks vote it adds one to the vote column in the database.
I want the users to log in with facebook and vote only ONCE for only ONE artist.
How would i go by doing such thing?
EDIT
This is a screen shot of the database I have.
database screenshot
Not sure where exactly you got stuck, and your question is way too broad for Stackoverflow, but here's how it works:
Authorize users with your Facebook App.
Whenever a user votes, store his ID with the vote and check if he already voted for that artist. A voting table could have the following 3 columns: artistId, vote, userId - or if the voting is not a number but just a flag, you could omit the "vote" column.
Links:
https://developers.facebook.com/docs/facebook-login
http://www.devils-heaven.com/facebook-javascript-sdk-login/
Related
So I have two different tables, a users table and an articles table. The idea is to allow a user to rate an article, but only allow them to rate it once (possible change their existing rating too but I can come to that conclusion later).
As of now I just have the update value working to allow them to rate the article, but of course a user can rate an article as many times as they want.
To give you an idea of how I have everything working, when a user logins in, a session is created with their user information. So when they go to rate an article, I have the ability to check the user, I just don't know how to stop them from rating if they have already rated a specific article.
The user table consists of among other things their username and their unique ID
and the article table consists among other things the article contents, the article unique ID, and the articles rating.
I had some really sloppy ideas like when the user rates an article their ID gets stored into the articles row in some kind of "users who have rated" column, and then I can do a for loop or something to siphon out all the user IDs and then check if their ID exists in that articles entry but then each article would have a row with possibly hundreds or thousands of userIDs on it and there seems like there would be a more elegant way.
Any help or direction is appreciated :)
Create a UserRatings table which has foreign keys to the users table and the articles table, and stores a row linking the user to the article, and the rating they gave it and when it occurred.
Then if a user tried to rate it again you just check this table for the user ID/article ID combination before allowing it.
And then if you wanted got can do things like show the user a list of articles they have previously rated, etc
Okey, so im trying to store the logged in facebook user´s friends list into a MYSQL table.
Im storing the logged in user data: ID and Name;
And am storing the logged in user friends list: ID and Name;
So the table looks like this:
['facebook_user_id'] ['facebook_user_name'] ['facebook_friend_id'] ['facebook_friend_name']
123123123123 User1 23424234234234 User 20
231321231231 User2 23424234234234 User 20
So you can see that user1 and user2 has the same friend and if user friend 'User 20' change his/her name I need to update the information, but only for the logged in user, so if user1 logs in the effect will only effect him/her.
But if user1 gets a new friend I need to insert the new friend and update if theres any changes.
How should I do this with PHP? I have seen something similar but didnt work that well for me.
INSERT INTO table (facebook_user_id, facebook_user_name, facebook_friend_id, facebook_friend_name)
VALUES ('facebook_user_id' (to short it down) .....)
ON DUPLICATE KEY UPDATE (facebook_user_id=facebook_user_id (and for every entry)....)
Thanks in advance, and any pointers will help me out alot.
I think this is what you meant.
I am trying to save user A Facebook friends into a table.
When someone logs in with Facebook I am storing, their name and Facebook id. As well as their friends, Facebook id and name.
This is how I would do it. Here is my solution if you need generated schema code let me know.
-Create three tables: registered users, buddies, lookup table
table 1: registered users
[id, userId, facebookUid]
table 2: buddies
[id, buddyid, buddy name]
table 3: You need a lookup table.
[id, userId, buddyid]
Steps:
When UserA logs in with Facebook, save their buddies into the buddies table
This approach above you don't have to worry about duplicate names. If someone updates their name, it will be changed across the board.
You can use join to find who has buddies in common.
So I'm wondering how sites like YouTube remember when a user has "Liked" a video and prevents them from liking it again. Similarly, how a site like Reddit remembers upvotes and downvotes and prevents a user from upvoting a piece of content they already upvoted.
Is it as simple as a database table where the ID of the content is stored along with the ID of the user and their response? I feel like that would become a massively huge table. Is there something trickier going on?
The sites require you to login before clicking on "like" and "upvote". The content document in the DB will have a field which will store the number of likes received. Before the like button is rendered, the sites will check against the logged in user's records in the DB, to check if he has already liked it- accordingly a "like" or "unlike" option is displayed.
If you check here in Stackoverflow, if you click "upvote" on your own question or answer, a message is displayed, that you can't upvote our own post. What happens is when you click "upvote", ajax request will be sent to server with the user ID and other information like question id etc. and the server code will check if you are allowed to upvote i.e your user ID should not be the same as the post creator's ID.
I have a like/dislike system on my page.
Database tables:
1.) One that contains your posts with a unique ID for each post and a user_id of who created it (along with other info like content, tags, etc).
2.) table called likes with AT LEAST the following fields, ID, post_id (corresponds to the post in the post table that was liked or disliked), user_id (corresponds to the user in the users table that did the liking/disliking), status (0 or 1, 0 being liked the post, 1 being disliked the post).
When a user likes a post, insert the row into the likes table with their user_id and the post_id, set the status as 0 (or just leave empty because 0 is the default). When a user dislikes a post, do the same but set the status as 1.
That way, on a post page you can get the count of all the users that liked or disliked a post. On a users's profile page, you can get all of the posts a user either likes or dislikes. You can also rank posts by which has the most likes or dislikes. Or even rank specific users by who has posted content with the most likes or dislikes.
Do not allow a users to like/dislike a post if they already have a record in the database. (Basically just check the count of records in the likes table where the post_id is equal to the current post and user_id is equal to the logged in user)
Cross reference the post table to get the post's author's user_id. If the post author user_id is the same as the logged in user, or the user is NOT currently logged in, do not allow them to vote.
The queries for doing all of those are simple (simply SELECT * or SELECT user_id) but that is the basic idea.
Yes, it's that simple. Generally, sites use ip addresses though, so that users don't vote twice on different accounts.
edit: Sorry, I was wrong. According to Quentin, websites don't base it off IP because of the possibility that multiple users have the same IP and aren't trying to exploit the system. Smaller scale sites (at least some of the ones I've used) have implemented a voting system based on IP because it would otherwise be easier to manipulate content ranking.
I need to set up a simple voting system for my application., My application consists of articles posted as well as comments. I would like to add voting abilities to both articles and comments and at the same time be able to sort comments based upon highest voted etc.
I have the following restrictions i.e since the application needs users to log in - only logged in users can vote, secondly a user can vote on an item only once. Users can upvote or downvote or cancel a vote they've made.
What would be a decent table design for this, plus I need the solution to be scaleable. Thanks for the advice
I think I would go with a join-table between the users and articles tables :
users_articles
- article_id
- user_id
- score
- date
With the following notes :
article_id is a foreign key to the article that gets up/down-voted
user_id is a foreign key to the user that voted
score is +1 or -1 depending on the vote
the primary key is on the two article_id, user_id columns.
a user voting on an article means inserting one line in this table ; canceling the vote means deleting that line (or setting a 0 score if you want to keep track of the fact the user has voted)
That's for votes on articles.
And I would do another users_comments table for the votes on comments.
Now i am working on a social network website and i already built the friends table for this website but i need some suggestion before i moved forward.
I have a user table where user_id is the primary field.
So for friends i made a friends table with fields like
friend1,friend2,is_active
what i do actually when user1 send a friend request to user2 then at that moment i insert the two rows into the friends table like
1- friend1->user1,friend2->user2,inactive
2- friend1->user2,friend2->user1,inactive
So when somebody accept the friend request at that moment i made the both rows as active.
I made this two entries as i want whenever one user block another then easily made that corresponding row belongs to that user will be inactive.
And if a user remove the user then at that time i delete the both entries.
So please i need some suggestion regarding this please help me out to solve this asap.
I need to know is there any other way which will be more optimized than this and giving proper result.
I think that
Friends_table
with
User_id1, User_id2 and Rleationship_id
is easier, index on both first and second column.
relationship id will be 1 - id1 request, 2- id2 request, 3 - friends, 4- id1 blocked, 5 - id2 blocked...
just an idea.