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

16

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

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

NOTES TABLE (id, userid, submissionid, message)

SUBMISSIONS TABLE (id, name, userid, filepath)

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

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

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

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

Ответы:

5

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

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.
задирать
источник
Каков наилучший способ применения «Решения № 2: Выделенная таблица трассировки данных» для приложения OLTP.
AA.SC
Компания, в которой я работаю, в настоящее время использует несколько схем, одна специально для журнала аудита. Таблица аудита действительно довольно проста при использовании решения № 2 (именно это мы и используем здесь, на работе). Разбейте другую задачу (обновлена ​​таблица инвентаризации, обновлена ​​или удалена информация о клиенте, предоставлены кредиты клиенту и т. Д. И т. Д.) И составьте таблицу аудита на основе общих действий, которые могут выполнять пользователи. Отвечает ли это на ваш вопрос относительно применения решения 2 к вашей базе данных, если нет, уточните, пожалуйста. Благодарность!
Гектор
На самом деле мы уже осуществляем аудит данных с помощью первого подхода с использованием таблиц аудита, но данные аудита становятся настолько огромными, и теперь мы хотим преобразовать наш подход, просто собирая данные по измененным столбцам. У меня вопрос, как я могу достичь этого подхода? Каков наилучший способ отслеживать, какой столбец таблицы изменяется? .. если в таблице более 20 столбцов, один из них с DataType Text.
AA.SC
10

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

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

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

TommCatt
источник
1
Очень хорошие очки! Тем не менее, я не совсем понимаю это This means no flag or other indicator showing which is the current version and which are "history.", если нет флага или индикатора, как мы отличаем текущую версию от версии истории? Особенно исходя из вашего третьего пункта, который, как вы предлагаете, должен быть в одной таблице.
GMsoF
Презентация показывает пример дизайна, включая запрос для чтения текущих и / или прошлых данных из таблиц. Если это выглядит достаточно интересно, чтобы заглянуть глубже, документ содержит гораздо больше деталей.
TommCatt