[eluser]vokic[/eluser]
[quote author="andrewtheandroid" date="1257522042"]Would this be ok for a group of around 500 users with light to casual forum usage in terms of performance?[/quote]
Well for that group I think you shouldn't even see any difference at all..
Just make additional field for thread in db like 'read' and when someone reads it add his user id into that field... When someone adds a reply, just completely delete that field and start again..
And when you do the display just compare:
Code:
if(strstr($thread['read'], $user_id)) echo '<a href="thread_url"><b>Thread title</b></a>';
else echo '<a href="thread_url">Thread title</a>';
or something similar
When someone goes to view the thread just add his user id if doesn't already exist:
Code:
if(!strstr($thread['read'], $user_id)) {
$thread['read'] .= ' '.$user_id;
$this->db->update('threads', $thread, 'id=thread_id';
}
That's actually all there is to it... But the troubles might start when you need to select only threads read by the user or threads subscribed..
There is that solution with LIKE : "SELECT * FROM threads WHERE thread_read LIKE $user_id" and we all know it will be slow for large records.. Maybe full text search would help at that situation... Then there are more solutions like: "SELECT * FROM threads WHERE LOCATE($user_id, $thread_read) > 0" or something similar which might be faster then LIKE etc.. It has flaws but hey, we are chatting about it
I would prefer thread based solution over user based solution because it is easier to maintain... Operations are done only on that one field while on user approach every time you update a thread (read/noread/delete) you would have to update each user record..
Maybe for subscriptions you can go even with standard way of thread_id, user_id table cause it will be much less than read/noread records..
