The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

This is bad database design. You're trying to use a single column of a single row for what should be its own table. It is not only slow and messy but unsound... your search matches users other than the one you're looking for!

Create a table which has a user ID and a post ID and insert a row when a user reads a post. One query to mark a post as read, and selects will be infinitely faster.

I was looking for "read/not read" threads highlighting, but I would like to avoid creating duplicate entries for every user and message id in separate table for every forum message.

What duplicate entries? There would be one row for each thread read by each user. No duplicates. That's the minimum amount of information needed to know if a user has read a post, and that's the most efficient way of storing it.

What duplicate entries? There would be one row for each thread read by each user. No duplicates. That's the minimum amount of information needed to know if a user has read a post, and that's the most efficient way of storing it.

Why do you want something worse than the optimal solution? Here's an alternative, but it'll be slower:

Create a table which relates threads to users, with an additional column containing the timestamp the thread was viewed (user_id, thread_id, time_viewed). Then keep track of the last post date on each thread in the threads/topics table. Intersect these tables on the timestamp being higher or lower to get read/unread threads for a user.

This comparison is slower than intersecting on the indexes of the table described above.