Форум MySQL

Есть таблицы БД (MySQL). Все записи, которые там есть, пренадлежат их авторам (по id). Авторы же могут свои записи редактировать (Само собой, все это через web-интерфейс на PHP :) ). Я хочу сделать отчет об изменениях в записях. То есть, если запись отредактирована, необходима информация, когда она редактировалась и что именно изменили (типа как в вики). Причем, необходимо все предыдущие варианты так же хранить в БД.

Подскажите, как такое реализовать? У меня мысли есть, но они какие-то нерациональные, на мой взгляд, получаются...
Я, например, думал так - при первом же редактировании сообщения, добавлять в таблицу флаг "2" (у нового сообщения всегда флаг "1"). Если сообщение редактируется еще раз, то флаг увеличивается на единицу.

Ну и затем все это выводиться через "...ORDER BY edit_flag;"

Но, с такими планами, думаю, база забьется данными очень быстро. Хотя, вообще, на этом "сайте" будут работать около 10-20 человек всего, возможно, одновременно... Записей в день будет прибавляться немало - около 100 от каждого человека...

Ну я наверно бы реализовал так:
1) создал новую таблицу, в которой бы хранил данные о всех внесенных изменениях ( почти полный аналог существующей таблицы, за исключением даты, которая будет отображать дату изменения, а не создания. И добавил бы еще одно поле, в котором будет указываться id (или любой другой уникальный номер записи)- он будет браться из существующей уже таблицы.
2) в существующей таблице добавил бы поле даты отображающие дату последнего изменения
3) когда автор вносит изменения, то данные существующей записи копируются в новую таблицу (1) и замещаются новыми данными.

Получается, что в новой таблице будут накапливаться все устаревшие данные. Благодаря указанию уникального id записи, можно будет вытащить только те изменения, которые касались конкретной записи.

Ну я так понимаю, что таким образом можно следить за последними изменениями, но не очень понимаю, как таким образом можно следить за ВСЕМИ изменениями и сразу.
Допустим, в одной таблице старая запись, в другой - новая + дата последнего изменения. Автор изменил еще раз данные таблицы. Они опять будут копироваться в новую таблицу (с тем же идентификатором и датой), а новый вариант записи будет уже в первой таблице?

Назовем исходную таблицу таблицей А, тогда предлагаемая мною дополнительная таблица будет иметь имя Б ).

1) автор пишент новую статью и добавляет ее в БД, запись осуществляется в таблицу А, например под id=14;
2) на следующий день автор решил подкорректировать свою статью и изменяет ее. Скрипт существующую запись под id=14 из таблицы А копирует в таблицу в таблицу Б. После этого новые данные записываются в таблицу А в запись под id=14. Где надо изменяет даты (устанавливает дату редактирования).
В итоге у нас появилось две записи, посвященные одной статье: одна в таблице А, другая в таблице Б. Получается в таблице А храниться самая новая статья (с указанием даты последнего изменения), а в таблице Б оригинал.

3) допустим автор еще раз подумал и решил еще раз изменить статью. Происходить тоже самое что указано в пункте (2), но уже в таблице Б будет 2 записи с id=14 (данное поле таблицы не будет Primary key, оно будет предназначено для установления номера статьи). То есть будет храниться оригинал статьи и ее первое изменение. При еще одном изменении в таблице Б будет храниться уже 3 записи, посвященные данной статье.

Все изменения данной статьи можно будет получить, сформировав всего один запрос "SELECT * FROM table Б WHERE id=14".

Еще раз хочу подчеркнуть, что PRIMARY KEY в таблице Б будет другой, не тот id про который мы говорим.

Я не знаю насколько это правильно, предлагаю лишь как один из вариантов.

спасибо, за подробности. Я примерно так и делоаю сейчас, только уникальные id в таблице я не меняю (имхо плохой тон), а просто делаю еще один "идентификатор" parent и уже работаю непосредственно с ним