in reply to Storing node revision history

The database is already under heavy load. The fine art of database retrieval involves getting the database to do as much as possible, in order to return as little as possible. It's therefor somewhat counter-productive to ask a database to fetch a somewhat lengthy string of bytes only to then reprocess it in order to use the last bit.

Theoretically, one would add a new table that contains the node_id, revision tuple and fetch the latest revision with select max(node_id), revision from latest_node_revision with a join on the node_id from some other table.

Pratically, that might be a net loss. It might be better to store revisions in the existing node contents. That would require significant reworking of the existing code to make sure it reprocessed the node contents to only pull out the last revision. Down that path lies madness. (Although if I had to envisage doing such a thing in other circumstances, I would encode the different chunks as MIME entities rather than reinvent that particular wheel).

I'm also pretty sure that nodes have a hard upper limit of 64kb. Storing multiple revisions of lengthy nodes would quickly blow past that limit. All other things being equal, a lengthy node is also more likely to be tweaked.

My feeling is that thepen's Perl Monk Archive is sufficient to get the (approximately) original view of the node. And if someone really wants to wipe out the contents of their nodes, these can always be restored from tape (this has happened before, with mt2k and tye in the roles of reaper and restorer).