CREATE TABLE revisions ( revision int PRIMARY KEY AUTO_INCREMENT, page text NOT NULL, title text NOT NULL, digest text NOT NULL, timestamp datetime NOT NULL, author text NOT NULL, ip text NOT NULL, host text NOT NULL, text mediumtext, -- can be NULL INDEX ( page(30) ), INDEX ( page(30), text(1) ), INDEX ( timestamp ), FULLTEXT ( text ) );
The revisions table uses a global revision counter to uniquely reference every edit made to the wiki. As SunirShah said, "This is an interesting design philosophically speaking: it says the wiki is primarily characterized as a set of changes."
The separate text column stores the text associated with each revision. Allowing it to be NULL allows ForgiveAndForget without losing the RC log, as stale revisions can simply have their text column set to NULL. Equally, deleting a page means simply deleting all text associated with it.
Some sample queries:
SELECT * FROM revisions WHERE page = ? AND text IS NOT NULL ORDER BY revision DESC LIMIT 1;
This query is optimized by the page-text index.
SELECT * FROM revisions WHERE revision = ? AND page = ?;
Note that the page = ? here is just a (redundant) verification, as revision IDs are unique across the whole db.
SELECT page, max(revision) FROM revisions WHERE text IS NOT NULL GROUP BY page;
SELECT * FROM revisions WHERE timestamp >= ? ORDER BY timestamp;
This query is optimized by the timestamp index.
SELECT revision FROM revisions WHERE page = ? AND text IS NOT NULL ORDER BY revision DESC;
This query is optimized by the page-text index.
With this design, post-PeerReview maintenance can be handled fast, without requiring strong isolation: