Home/ Questions/Q 8933043
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-15T09:26:40+00:00

For a project I am making I need the possibility (like stackoverflow does) to

  • 0

For a project I am making I need the possibility (like stackoverflow does) to save all the previous edit (revisions) for posts.

Consider I can have some 1 to N association with the post (for example 1 post with 5 images associated).

How would you suggest me to design the database for this?
Of course the ID of the post should stay the same to don’t broke URLs:

site/post/123 (whenever revisions it is)

Each revisions to posts should be manually approved so you can’t show directly the last revisions inserted. How would you suggest me to design the db?

I have tought

Table: Post
postID | reviewID | isApproved | authorID |  text

And the image table (for example image, but it could be everything)

Secondary Table: Image
imageID | postID | reviewID | imagedata
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Actually, I would split the post table in two, with the approved revisions in one, and the latest (not approved) revision in another. The rational is that any non approved revision which is not the latest would be supersceded by the next one (unless you really want to keep track of all the intermediate modifications, approved or not).

    Table: OldPost
  postID | reviewID | authorID |  text

Table: PendingPost
  postID | authorID |  text

    In that layout, whenever a new revision has been approved, it must be moved to the approved ones, but you don’t have to filter them out when displaying the whole history, and conversely, you wont have to filter the approved revisions in the approval part of your site.

    You could even refine the layout with yet another dedicated table for the latest approved revision (so three tables for the post in total, not counting attachements). This partitioning would improve the overall performance of your site for the most common queries, at the cost of more complex queries when you need all the data (less frequent operations).

    Table: CurrentPost
   postID | authorID |  text

    As you can see, this table structure is the same as the one for pending posts, so the updates would be trivial.
    moving a revision to the old post table requires to find out the revision count, but you would have to do that operation anyway with a more classic db layout.

    Regarding the attachment table, the layout seems to work.

    • 0