tags:

views:

357

answers:

3

Hi,

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. Don't know how do forum systems like MyBB, vBulletin, IPBoard, 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, I'd like to read from you what do you find as the best practices for this issue, as well as how other forum systems cope with it.

Cheers!

+1  A: 

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.

Laykes
What about each user's thread viewed / opened? What you suggest seems to imply that I cache every user information...
yoda
You load it once when the session starts or after a certain amount of time has gone by. The cache is in the session, not a big permanent cache.
jmucchiello
+1  A: 

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.

wimvds
Better forum software will give you last read data PER forum at a minimum. Extreme forum software actually keeps track of what you've read.
jmucchiello
Nothing new, sorry. Thing is, the last user activity redards the hole forum, not each thread, wich means that for that to work properly I'd still need to track the timestamp regarding each thread.
yoda
What's a hole forum? Is that like `/dev/null`?
Billy ONeal
the hole forum is all the boards / categories / topics in it
yoda
+1  A: 

There isn't a lot of choises.
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 unreaded 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 dont 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, ie:
1 and 3) show thread as "unread" if they arent older than X days and there isn't a row marked as readed for the user. The "readed" rows can be deleted when are X day olders without affect anything.
advantages
*less spaced used to determine unread threads
disadvantages
*create a cron that keeps the system clean
*Users dont know if they read threads olders than x days.
advantages
*Every user knows wich "new posts" has read or not.

useless
I still think there must be a easier way to do it. I thought about using MemCache, but it relies on memory, and I'm still thinking about APC. If I could have some sort of cache file to work with, would probably help.
yoda