I would have two tables, one for topics and one for replies.
Topics would have a column called 'topic_last_updated' or similar. When a topic is created, the 'topic_last_updated' field is set to be the same as the 'topic_created' date. Whenever a reply is posted in that topic, the topics 'topic_last_updated' field gets set to the date time of the reply.
Then you only have to order_by the 'topic_last_updated' field.
I might even add a 'topic_last_reply_id' so a simple join brings out the last reply details too, so if there is a reply, you can show a snippet of the last reply or the username etc. Also a 'topic_reply_count' that increments for each topic added. Plus 'topic_viewed_count' too. Also a 'topic_visible_to_public' Boolean so admins can disable topics, plus a 'topic_deleted' Boolean for soft deletes, plus probably many more. Anything you need to know about the topic should not rely on further queries. I know you can count replies and add it to the SQL query result set, count views (if you have that data table somewhere) etc, but I do believe in simplicity. How easy would it now be to show topics sorted on the most popular, trending, the highest rated, the most replies etc.
Running queries based on a foreach of the results of another query is always (at least it seems to me) going to be problematic. If you have 100 topics, you are running 100 subsequent queries just to sort them.
Hope that helps,
Paul.
