No, I don't have a topic table. The predicate for that 'wall_comments' table is
'topicID' is the thread of discussion, on the wall of member 'wallmemberID', onto which member 'posterID' posted comment 'comment' at time 'posted'
commentID is an extra key that I added when I mapped the relvar to MySQL
IF you go to kkrueckeberg.userworld.com/social and sign in (it is just a demo site) and login as 'firstname.lastname@example.org' with password 'abc123'. Then click on Wall. You will see a 'Start New Topic Form'. That is how a user starts a new topic.
I guess it would make sense to have a 'topics' table if the topics table also had a 'last_updated' attribute of DATETIME, indicating when the thread was most recently updated. Then I wouldn't need the subquery, involving 'MAX(posted) ... GROUP BY(topicID)' to get the most recently updated thread:
FROM wall_comments AS wc
JOIN ( SELECT topicID
, MAX(posted) AS latest
BY topicID ) AS mmm
ON mmm.topicID = wc.topicID
JOIN member_info AS mi
ON mi.memberID = wc.posterID
BY mmm.latest DESC
, posted DESC
Yes, I bet that query does look familiar. And I now realize that wallmemberID is functionally dependent on topicID, because each topicID will be on one and only one member's wall (of the social network). wall_coments therefore isn't even in Boyce Codd normal form because the topicID is not a super key of wall_comments. I decomposed wall_comments into wall_topics and wall_comments.
create table wall_topics(topicID int unsigned NOT NULL auto_increment,
wallmemberID int unsigned NOT NULL,
primary key (topicID),
foreign key (wallmemberID) reference member_info(memberID));
create table wall_comments(commentID int unsigned NOT NULL, auto_increment,
topicID int unsigned NOT NULL,
posterID int unsigned NOT NULL,
posted DATETIME NOT NULL,
unique key(topicID, posterID, posted),
foreign key(topicID) references wall_topics(topicID),
foreign key(posterID) references member_info(memberID));
Now I need to re-visit the query to see if i too needs changing. Thanks for the replies!