Лучший способ создать базу данных и таблицу, чтобы вести учет изменений?

Мне нужно настроить функцию истории в проекте, чтобы отслеживать предыдущие изменения.

Допустим, у меня есть две таблицы прямо сейчас:

NOTES TABLE (id, userid, submissionid, message)

SUBMISSIONS TABLE (id, name, userid, filepath)

Пример: у меня есть строка в заметках, и пользователь хочет изменить сообщение. Я хочу отслеживать его состояние до изменения и после изменения.

Каков наилучший подход к настройке столбца в каждой из этих таблиц, в котором будет указано, является ли элемент «старым». 0, если активен, ИЛИ 1, если удален / невидим.

Я также хочу создать AUDIT TRAILтаблицу history ( ), которая содержит idпредыдущее состояние, idновое состояние, к какой таблице относятся эти идентификаторы?

Пожалуйста, просмотрите

http://www.codeproject.com/Articles/105768/Audit-Trail-Tracing-Data-Changes-in-Database

Это очень хорошая статья о подходах к созданию контрольного журнала в вашей базе данных. Контрольные записи необходимы для реализации базы данных. Вы всегда должны видеть действия пользователей базы данных в системе.

Мы можем отслеживать, какие строки были изменены в нашей системе PTA (Point in Time), добавив некоторые стандартные столбцы PTA (point in time) во все таблицы, представляющие интерес для PTA.

Я предлагаю следующее:

DateCreated – the actual date on which the given row was inserted.
DateEffective – the date on which the given row became effective.
DateEnd – the date on which the given row ceased to be effective.
DateReplaced – the date on which the given row was replaced by another row.
OperatorCode – the unique identifier of the person (or system) that created the row.

При разработке возможностей управления версиями в ваших данных, существует несколько минимальных (я бы подумал) требований:

• Каждая версия данных должна быть автономной и независимой от других версий. Это означает отсутствие флага или другого индикатора, показывающего, какая версия является текущей, а какая - «историей». Это также означает, что обновление сущности означает вставку только новой версии - обновление предыдущих версий не требуется.
• Избегайте того, что я называю зависимостью от связывания строк. Именно здесь одно поле (End_Date) строки должно синхронизироваться с другим полем (Start_Date) другой строки. Это усложняет работу с данными и является отличным источником аномалий.
• Текущая версия и все предыдущие версии должны быть в одной таблице. Это позволяет использовать один и тот же запрос для просмотра прошлых данных «по состоянию» на определенную дату и для просмотра текущих данных.
• Внешние ключи к версионным данным должны работать так же, как обычные (неверсированные) данные.
• Дизайн должен быть настолько простым или понятным, что кривая обучения для новых разработчиков сводится к минимуму.

Вот слайды презентации, которую я несколько раз делал на технических ярмарках. Он охватывает, как все вышеперечисленное может быть сделано. И вот документ, который идет в более подробно. Я должен принести извинения за документ - это работа, и не все разделы заполнены. Но он должен дать вам всю информацию, необходимую для реализации чего-либо, от простого управления версиями до полного двунаправленного доступа.