Page 1 of 1
how to design??
Posted: Sat Sep 29, 2007 8:25 am
by claws
hi..
I have made my own forum.
my problem is,
when a user logs in. all the post that user have not read should be higlighted.
how to do that??
i have 2 tables.
1 for threads
other for replies.
but each entry of this table should appear with different read status for different users.
how to optimally do this??
Posted: Sat Sep 29, 2007 8:31 am
by feyd
Select all threads/replies that are younger than their last known visit time. Add logic to your output that will highlight matching topics/replies in whatever manner you wish.
Posted: Sat Sep 29, 2007 8:39 am
by claws
but say,
If user has logged in and didnt checked any posts. and simply logged off.
next time when he visits all his posts will be marked as read.
which is actually not true..
Posted: Sat Sep 29, 2007 8:51 am
by feyd
But they are old. You want to persist the read data? If so, you'll need a table to hold a reference between users and posts they've read. This table will get HUGE.
Posted: Sat Sep 29, 2007 10:50 am
by Oren
claws wrote:but say,
If user has logged in and didnt checked any posts. and simply logged off.
next time when he visits all his posts will be marked as read.
which is actually not true..
That's true, and I suggest you to check on this forum... try to log out and then log in. You'll see all posts as read - even those you haven't read.
Posted: Sun Sep 30, 2007 12:54 am
by ayvah
claws wrote:but say,
If user has logged in and didnt checked any posts. and simply logged off.
next time when he visits all his posts will be marked as read.
which is actually not true..
I've seen this implemented in vBulletin. I'm not sure whether it's built into the core script, or whether it was implemented in an add-on. Nonetheless, the functionality is there.
Even phpBB implements a mild, session-reliant version of this functionality, which tracks the threads you view before the expiry of the session.
To my knowledge, the best strategy would be to set aside a column in the thread table, containing an imploded array with the user ids of those who've seen it. This can then be compared to the user in question to determine if they've seen the thread. You can even generate a list of the users who've viewed the thread, if you feel like it.
PS You could possibly expand this to two columns. One for those who've viewed the thread. Another for those who've viewed it since its last update.
Or change the scheme from "5,24,55", denoting user ids, to something like "5:1239473,24:1239473", so that it contains both the user id and a timestamp, which you can compare to the individual posts in the thread, to highlight the ones that are new.
Posted: Sun Sep 30, 2007 7:52 am
by feyd
ayvah wrote:To my knowledge, the best strategy would be to set aside a column in the thread table, containing an imploded array with the user ids of those who've seen it. This can then be compared to the user in question to determine if they've seen the thread. You can even generate a list of the users who've viewed the thread, if you feel like it.
PS You could possibly expand this to two columns. One for those who've viewed the thread. Another for those who've viewed it since its last update.
Or change the scheme from "5,24,55", denoting user ids, to something like "5:1239473,24:1239473", so that it contains both the user id and a timestamp, which you can compare to the individual posts in the thread, to highlight the ones that are new.
Actually, that's one of the worst. Why? The size of string based columns is limited. The length of a user id varies based on when the user signed up. Newer users will have longer values. Therefore the quantity of users that can be marked as reading any given thread varies as a function of the user id length. That's really bad.
Even worse, querying and working with this column turns into a nightmare at the query level and management code level.
Posted: Sun Sep 30, 2007 6:03 pm
by ayvah
Noted.
Though if you have a billion users, all at the full nine digits, you can still fit over 1.6 million of those into a mysql MEDIUMTEXT type column if it's just the user id separated by a comma, and that's before we consider base64 and LONGTEXT. By the time you break the capacity of a longtext column, you may be wondering where all those gigabytes went.
Querying the column isn't too much of an issue. It depends on how you wish to use the data. If there's a comma before every user id (including the first), you can simply fetch the column from the selected row when you want to find out if the thread has been read, and do a strpos($col, ','.$id) !== FALSE to see if the user id appears. This seems effective enough if all you want to do is highlight unread threads that are going to be displayed anyway, and don't need the capability to actually search for them.
There are issues in this method. I'm certainly no expert on making scripts super duper fast but the limit of a string in a mysql column isn't really the top-billed issue.