jbert's points about maintainability are well taken. A similar point that occurred to me as I read the two descriptions: what sorts of things can go wrong with each solution, and what would be the relative consequences in each case?

For example, suppose someone is doing "table maintenance" (i.e. using some more general-purpose interface to the database, not the website cgi scripts), and makes some sort of mistake involving "update posts_tbl set deleted_flag=0 where ..." Suddenly, posts that had correctly been deleted are no longer marked as such in this field. Under approach A, their contents still won't appear on the website, whereas in approach B, they will. The converse case ("set delete_flag=1 where ...") will play out in a similar way.

If that sort of thing could happen, then of course it will (cf. Murphy), and in that scenario, using approach A might be better for the sake of your readers. Then again, that sort of "table maintenance" becomes harder to do under plan A, because you have to copy the message content into one table and also delete it from the other, in addition to (re)setting the "deleted" flag. Of course, you can define stored procedures for "deleting" and "undeleting" posts to make this less of a problem.

That said, I would still go with bart's idea because it's simpler, and that extra simplicity is well worth the trivial cost of adding a column or two to the posts_tbl that will be null in the vast majority of rows. It does expose you to the sort of mishap scenario I described above, but that's what rollbacks and backups are for...