I've had an idea to make my website viral: a competition where the users make points and they win prizes. One of the ways they can get points is the following: if they share their personal page (they made on my website) on facebook they get 1 point for each like they get.
Then i made a PHP script which periodically queries facebook to ask the like_count the URL got. It simply queries for the like_count column in the link_stat table and then it evaluates the score.
PROBLEM
I've found a trick: if i share my personal page URL 100 times and then i like all the 100 links i shared (on facebook), like_count goes to 100. Which is bad for my competition, because as soon as someone finds this out, he will easily win the competition.
What i want to get, instead of like_count, is the number of distinct people who liked that URL.
This means, if i share the URL 100 times and i like it 100 times, my girlfriend likes it 30 times and my grandmother likes it 10 times, instead of 140 the count should be 3.
This way the competition would be perfectly regular.
Any ideas?
Maybe you can do it with this https://developers.facebook.com/docs/reference/fql/like/ which says something like this:
SELECT ... FROM like WHERE object_id = ...
Basically it returns the people who liked certain object, which I assume would be 1 for you even if you like the same link 100 times?
Related
I have been stuck on this FOREVER and I would be so grateful for another perspective. I have a table tracking website views and need to query the number of people who visited one page only. My Table is similar to below:
SESSION_ID PAGE
------------------------
122 HOME
122 CONTACT US
123 HOME
124 HOME
I need a way to count the number of sessions that only show up once in the table (only viewed one page). IE: In the above: what query would tell me that 2 people viewed only one page.
I would love to post what I have tried, but I honestly have no clue where to start. I am thinking something like:
$query=mysqli_query(con,"SELECT count PAGE as pages_viewed FROM analytics WHERE pages_viewed='1' GROUP BY SESSION ID");
$singleViewRows= mysqli_num_rows($query);
But I don't think that is it? Maybe I need a subquery in there?
Thank you again for all help!
If I understood well, we are interested in the number of session here, so counting pages wouldn't give the expected result.
So what about the following query:
SELECT session_id, COUNT(session_id) FROM analytics GROUP BY session_id HAVING COUNT(session_id) = 1
Selecting COUNT(session_id) is optional but it'll give you the confirmation you fetched only the ones with 1 record in the table.
I have a screen that looks very much like facebook timeline
users can view posts of other users etc.
to get these posts i do something like
select user.id,user.name,posts.title,posts.body from posts left join users;
now data i need to collect is "Who saw this post" .
is there any elegant way to do it ?
right now all what i can think of is every time i fetch posts. i loop over them, then collect all ids of posts that the query returned and then push in another table
user_views [pk:user_id+postId]
userId,postId
1 , 1
Then when i'm fetching posts next time i can do count of user_views.
select *,count(user_views.id) from posts join user_views on post_id = post.id
but this sound like a lot of work for each VIEW, specially that most probably user will see a most multiple times,
is there any known patterns for such need ?
This is a design question and the answer really depends on your needs.
If you want to know exactly who viewed what post and how many times, then you need to collect the data on user - post level.
However, you may decide that you do not really care who viewed which post how many times, you just want to know how many times a post was viewed. In this case you may only have a table with post id and view count fields and you just increment the view count every time a post is being viewed.
Obviously, you can apply a mixed approach and have a detailed user - post table (perhaps even with timestamp) and have an aggregate table with post id and view count fields. The detailed table can be used to analyse your user's behaviour in a greater detail, or present them a track of their own activities, while your aggretage table can be used to quickly fetch overall view counts for a post. The aggregate table can be updated by a trigger.
Background Info :
I'm trying to retrieve images from people I follow, sort by latest time. It's like a twitter news feed where they show the latest feed by your friends.
Plans:
Currently there is only 1 item i need to keep in consideration, which is the images. In future i'm planning to analyse user's behavior and add in other images they might like into their feed, etc.
http://www.quora.com/What-are-best-practices-for-building-something-like-a-News-Feed
I personally feel that "Pull" Model, or Fan-out-on-load where i pull all info at real time would be worst than the push model. Because imagine i have 100 following, i would have to fetch and sort by time. (Let me know if i'm wrong eg, Read is 100x better than Write(Push Model)
The current design of the push model i have in mind is as follows
Table users_feed(ID, User_ID, Image_ID,datetime)
Option 1 : Store A list of Image_ID
Option 2 : Store one image ID and duplicate rows(More Rows of same User_ID but different Image_ID)
The plan is to limit each Row a user can have in this feed , which means , there would always be a max of 50 images. If they want more items beyond the 50 images in their news feed. They cant(I might code a alternative to store more so they can view more in future)
Question 1
Since when user following users add a item into their "collection" i have to push it into each of their follower's feed. Wont there be a problem in Write? 200 followers = 200 writes?
Question 2
Which method would be better for me keeping in consideration that i only have one type of data which is images. Feeds of images.
Question 3
If i choose to store the feed in advance(push method) how do i actually write it into all my friends?
Insert xxx into feeds whereIn (array of FriendsID)?
Any form of advice would be greatly appreciated. Thanks in advance!
I would recommend you to follow pull method over push method for the following reasons:
It gives to more freedom for extencibility in the future.
Less number of writes ( imagine 10M followers then there has to be
10M writes for just 1 post).
You can get all feed of a user simply by query similar to:
SELECT * FROM users_feed as a WHERE a.user_id in ( < //select all
user_ids of followers of loged in user// > )
(Syntax not followed as table
structure of followers is not known)
I am working on a social network website project. I have created database and everything.
The posts table has a preference column which stores the preference value according to the likes and comments that a post gets from the users and also the time at which the post is created.
To retrieve posts for a user's home page from the posts table, I am running a query using joins which sorts using preference column .
Now, suppose I retrieve 10 posts for a user to be shown on the posts table and user scrolls down and one more request is made from the user to retrieve next 10 posts to the server.
If in between of those requests few other users creates a new post or preference value of posts in the database changes in the between, and now if I the second request is run on the server, all the posts will be resorted for the second request (i.e. to show next 10 posts) but since the database is updated , this means in the second request there will be many chances that few of earlier 10 posts are retrieved along in the second request.
I want to know how to avoid these duplicate requests.
How facebook or any other social network solves this problem at the backend when their database is dynamic.
I would rather avoid such unreliable way of sorting at all.
As a user, I'd rather quit that service. Frankly, I hate such too smart a service which decides which posts I have to see and which not. And even dynamically ordered on top of that.
Make it ordered by date, by tags of interest, by something sensible, reliable and constant.
In your script store a record of the rows id returned.
For example, using a basic limit and just storing the latest id when the first select is done, and using the page number to determine the limit of records to return.
SELECT id, somefield
FROM SomeTable
WHERE id < $SOMESTOREDVALUE
LIMIT $PAGENUMBERTIMESTEN, 10
or storing the latest id after each page is returned (which you will need to store each time this is run)
SELECT id, somefield
FROM SomeTable
WHERE id < $SOMESTOREDVALUE
LIMIT 0, 10
If you store the time & date when the user first makes a request in a session, you could use that to filter the posts table.
So your SQL for the second page of results would be along the lines of
SELECT <some fields> FROM <sometables>
WHERE DatePosted <= $timefirstseen LIMIT 10, 10
Where $timefirstseen was loaded from the session variable. This will restrict your results to only posts that existed when the users visit started.
You would of course need to include a feature to allow the user to clear the session or do that automatically when they revisit their homepage to make sure they got to see the new posts eventually!
I am making a website where you can like blog posts as well as user updates, so should I use insert statement for each likes of user passing post/blog id's or should I use an array and save likes of user in a single comma separated array
Like this:
Post 1 Example SQL:
-------------------------------------------
Likes(user_id) postid
-------------------------------------------
user1 post1
user2 post1
Or Array
-------------------------------------------
postid likes
-------------------------------------------
post1 user1, user2, user3
Moreover how facebook shows posts on wall randomly, I mean if I store updates in a table and when I loop using those updates, I get updates in line, now How I can add photos uploaded in between or a person adding another as a friend etc etc, I mean are they showing news feeds and linking with the original posts
Do you ever care about getting the individual likes back, unliking something, searching for likes by user, or perhaps even searching for likes by friends of a user? If so, save one record per user-post, and don't use a comma-separated list/array. The list/array will get unmanageable very quickly and honestly, they are just not what relational databases are good at doing.
If you need to display a comma-separated list on the screen, you can use GROUP_CONCAT to get a string for display.
As far as the second question goes, I'm sure there's some sort of "complicated algorithm" going on, based on what the user often clicks on, to show the user more of "what they like" from their friends. After that it's probably just a random smattering of all kinds of "wall-item" in newer-things-first order, where "wall-item" can be of type (update, news, video, image, check-in, app-access). I additionally suspect there's something else going on with the ordering, because the order is most definitely not posting time, nor last time touched.
I also remember way back when some user settings where you could choose the weightings of different kinds of posts (e.g. 10x updates, 3x news, 5x video, 5x image, 1x check-in, 1x app-access) which would change the "randomness" of what comes out the other end. In this case, naively, it would be 1d25, mapped to 1-10=>updates, 11-13=>news, 14-19=>video, etc.