When you first decide to implement "Undo" or "Revision History" in your PHP application, your instinct is probably to keep everything in one place. You've likely thought: "I'll just add a version column to my articles table. Every time someone hits save, I'll just insert a new row with an incremented version number."

The Single-Table Versioning Trap

It sounds clean, but in practice, it's a performance nightmare. Let's look at why. Imagine you have 1,000 articles, and each has an average of 10 revisions. Your table now has 10,000 rows. Every time you want to display your "Latest Articles" list on the homepage, your query looks something like this:

SELECT * FROM articles 
WHERE id IN (SELECT MAX(id) FROM articles GROUP BY original_post_id);

I've seen this approach crash production databases. As the history grows, the "simple" act of fetching the current version of a page requires the database to scan through thousands of obsolete rows just to find the one that actually matters. You're forcing the DB to do a massive amount of work for the 99% of your users who don't care about the history—they just want to read the current post.

Decoupling Current State from History

The professional way to handle this is to separate the Current State from the Audit Trail. You need two tables: one for the "Live" content and one for the "Revisions."

The articles table stays lean. It holds the current title, current content, and the current version_number. The article_revisions table is where the bulk of the data lives. It's essentially a write-only archive until someone explicitly asks to see a previous version.

Here is the logic I typically use when saving a revision:

• Step A: Fetch the current record from articles.
• Step B: Insert that current record into article_revisions. This ensures the "old" version is safely archived before it's gone.
• Step C: Update the articles table with the new content and increment the version_number.

In PHP, your save logic would look something like this:

// Assume $db is your PDO instance and $postId is the article being edited
$current = $db->prepare("SELECT * FROM articles WHERE id = ?");
$current->execute([$postId]);
$article = $current->fetch();

// 1. Archive the current version before overwriting it
$archive = $db->prepare("INSERT INTO article_revisions (article_id, content, version) VALUES (?, ?, ?)");
$archive->execute([$article['id'], $article['content'], $article['version']]);

// 2. Update the live table with new content
$update = $db->prepare("UPDATE articles SET content = ?, version = version + 1 WHERE id = ?");
$update->execute([$_POST['content'], $postId]);

Notice how this keeps your read queries lightning fast. When you want to show the article to a visitor, you just SELECT * FROM articles WHERE id = ?. No joins, no subqueries, and no scanning through ten years of typos and edits. You only touch the article_revisions table when the user clicks "View History" or "Restore this Version."

One last tip: don't version everything. If you have a last_edited_by or view_count column, don't put those in the revisions table. Only archive the fields that actually represent the content of the work. There's no reason to store 50 copies of a view counter.

📋 Practical Task

Build a "Restore to Version" Logic for a Wiki Page

You have two tables: wiki_pages (id, title, content, version) and wiki_revisions (id, page_id, content, version).

Your task is to write a PHP function restorePageVersion($db, $pageId, $versionToRestore). This function must:

1. Verify that the requested version actually exists in the wiki_revisions table for that specific page_id.
2. If it exists, take the content from that revision and update the wiki_pages table.
3. Increment the version number in the wiki_pages table (because restoring a version is, in itself, a new edit).
4. Return true on success or false if the version was not found.

Constraints: Use PDO for all database interactions to prevent SQL injection. Ensure you handle the case where a user tries to restore a version that doesn't exist without crashing the script.