141 votesOrbis Tertius commented
I'm not sure how wikis do it, but the most reliable way I've found to do this is with separate history tables that tracks insert/update/delete queries on a given data table via triggers. It's important to put the logic in triggers, rather than in the application, since frequently the sort of behavior that prompts an audit isn't done through the official means provided by an application. Typically the history table is identical to the data table, with the addition of a numeric or datetime column that when combined with the original table's primary key makes a unique composite key, to track changes to individual in sequence.
See 'Chapter 8 - Retaining a Tracking Log' here: https://www.cs.arizona.edu/~rts/tdbbook.pdf
That uses datetime columns as the 'sequencing' column. A *much* easier way to do it is explained here: http://stackoverflow.com/questions/12563706/is-there-a-mysql-option-feature-to-track-history-of-changes-to-records/12657012#12657012 , which takes advantage of some features MyISAM has when doing composite primary keys.
I think Fabrik could easily create and track those triggers with some information_schema querying, and even provide a way to update them when the schema of monitored tables changes. This would be a very nice feature for Fabrik to offer, to be able to just click a checkbox and have all the history tables and triggers created automagically, and maintained behind the scenes.