[ACCEPTED]-How "View Count" is best implemented?-schema
You have a couple of options as I see it.
You 24 can store a cookie in the users browser 23 for each page you are logging views on. Check 22 for this cookies existence and don't log 21 a view if the cookie already exists.
Downside 20 to this is that it won't work if cookies 19 are disabled or someone is trying to game 18 the system.
On the plus side you don't have 17 to worry about the storage of potentially 16 millions/billions of rows of table data.
You 15 hold a record for each view. Relating that 14 record to a user in some way e.g. MemberID, IP 13 Address; something that should be unique 12 to the user. IP is not ideal but good enough 11 if you are not requiring users to login.
So 10 you would have for example a table with 9 the following columns,
- ArticleID (Foreign Key)
- UserID (Foreign Key)
The date will be useful 8 for a couple of reasons,
- Reporting. You can build much better statistics once you know when each view was recorded.
- View Timeouts. For example, you may only want to store one view per user per hour. With the date column held you can do this.
If your application 7 gets popular in this situation then you 6 will need to deal with the storage implications. I 5 run a popular Facebook app which results 4 in over 100,000 view rows being added each 3 day. Realistically though if your app gets 2 so popular that it becomes a problem then 1 you'll have much bigger issues to deal with.
On my website I deal with counting guest 24 views and the 'mass of data' this produces 23 by dividing down the number of views using 22 a random number.
Say I have a random number 21 generator with a good distribution between 20 0 and 1, and I'm getting 100,000 views a 19 day on a particular page. If I call the 18 'logView()' function every view, but in 17 it generate an new random number and only 16 really log the view to the DB when the random 15 number is < 0.001, then for the 100,000 14 views I will only hit the DB approximately 13 100,000*0.001 = 1000 times.
If I want to 12 return a view count, then I just divide 11 my DB number by the same value, eg. 1000/0.001 10 = 100,000. This is approximatly accurate 9 to the nearest 1000 views.
Obviously you 8 can choose a random number range dependent 7 on the load of your site, and even change 6 this if your load changes dramatically (you 5 just need to modify your stored values accordingly).
Also, a 4 page with only 1000 views may not even get 3 a 1 in the view count, but if you have a 2 page with 100,000 views, then the one with 1 1000 is pretty insignificant.
Short answer: It depends!
- It really depends on how accurate you need your view count to be, is it acceptable that one person might be registered two or three times?
- It depends on what you're gonna use the data for. If you want do other neat things with the data (statistics, recent view list and so on) you might want to consider storing all the individual views in a database. This might result in a huge table so you have to thing this through before implementing it.
I've previously 6 used cookies combined with an in-memory 5 database to store the individuals view's 4 (for obvious reasons I stored the actual 3 view count in a database table persisted 2 to disk). I could do this because the statistics 1 didn't mean anything.
It looks like stackoverflow does not count 11 guest (unlogged) users viewing a topic. The 10 issue with counting anonymous user views 9 is that your counter can be gamed. Someone 8 can always delete the cookie and view again. Logging 7 the views is the safest solution for accuracy, but 6 of course you have two major problems: size 5 of the table and lack of guest/anonymous 4 users. It surprises me that stackoverflow 3 is not logging guest (unlogged) users. I 2 would think that the majority of views would 1 come from these users doing google searches.
When most of the visitors to your site are 4 registered it's relatively easy to make 3 sure none of them are counted twice.
I'm 2 not sure if SO counts views by guests. I 1 suppose I could check but it's late.
I'll try to give an answer from the functional 9 point of view.
count views per user - for 8 registered users. for anonymous users - per 7 session.
increment view count on the first 6 view and on any view after a significant 5 update by someone other that the person 4 viewing the item.
view of poster at the time 3 of creation should not count
you can imagine 2 doing it simpler too, but I've tried to 1 think of an ideal solution.
More Related questions