Storing revisions and relations between revised items in 1:N and N:N scenarios for audits
You have tradeoffs to consider when deciding on the design.  Which do you want to optimize for:


Insert new item
Revise item
Fetch "current" item
Fetch some old revision
Fetch all revisions


If one of those actions dominates, then design for it, and kludge for the rest.

Also, do revisions need extra columns, such as revisor, revision_date, revision_number, ...?  This may 'force' you to have a separate table for revisions.

If not using a separate table, consider this design:

Have a column rev for revision number:  0 for "current"; 1...N for old versions (1 is oldest).  Then it takes a couple of statements to move 0 to N+1 and insert a new 0.  The Fetches are pretty obvious.  Include an composite index (the PRIMARY KEY?) in this order: (rev, item_id).