PHP forums - how to cope with unread discussions / topics / posts

user_168177 0
Viewed 7650

I know this question has been asked here a couple of times, but none of the answers had pleased me. This is because almost all of them involve a huge read / write process related with the database, which I'd like to avoid at all cost.

About unread discussions / topics / posts, there's a lot to think of. I don't know how do forum systems like MyBB, vBulletin, Invision Power Board, Vanilla, phpBB, etc., cope with that issue, so I'd like to read from you guys your experience with that. I know that using a database table just for that is the simplest way, but that would involve a huge read / write when the community has over 10,000 members and 1000 new topics every month. It's hard, but there should be a way to avoid the server's overloading.

So, what do you find as the best practices for this issue, as well as how other forum systems cope with it?

forum mysql php
7 Answers

There isn't a lot of choices.

  1. mark every reader thread by each user.

    • Disadvantages: a lot of rows in very active forums
    • Advantages: Every user knows with post has read or not.

  2. mark every unread thread by each user.

    • Disadvantages: a lot of space with "unreaded" rows if there is inactivity of a lot of users
    • Solutions: add a lifetime timestamp and delete old records with a cron
    • Advantages: Every user knows with post has read or not.

  3. use timestamps to determine if show it as unread or not.

    • Disadvantages: The users don't know with are the real unread threads, the marks only show the "new trheads" since the last login
    • Advantage: Save space

The other alternative is mixing solutions, that is,

1 and 3) show thread as "unread" if they aren't older than X days and there isn't a row marked as readed for the user. The "read" rows can be deleted when they are X day older without affect anything.

Advantages

  • less spaced used to determine unread threads

Disadvantages

  • create a cron that keeps the system clean
  • Users don't know if they read threads olders than x days.

Advantages

  • Every user knows which "new posts" has read or not.
user_2673510

Why are you concerned?

I don't see an issue with any I/O for getting the unread threads. It doesn't have to be live. A 15 minute delay based on a cache value would work.

So for unread threads you just

Pseudo code..

$result = SELECT id,viewcount from my_forum_threads

$cache->setThreads($result['id'],$result['viewcount']);

Then on a page load you just get the cache values rather than querying the database again. Its really not a big issue at all.

The average page on my website takes 20 mysql queries. When I cache it is only two to four queries.

user_1945280

Almost any forum I know of will use some sort of reference timestamp to determine whether or not a thread/message should be regarded as "unread" or not. This timestamp usually is the date/time of the last action you performed on your previous visit to the forum.

So you keep ie. a previous_last_action & last_action timestamp in your user table, last_action is updated on every user action, the previous_last_action column is set once to last_action when logging in (or upon creation of a new session - if you have "remember me" functionality). To determine if a thread/message is unread you would compare that thread/message creation (or update) timestamp with the value in previous_last_action for the user currently logged in.

user_1098220
Related