Таблица истории базы данных / таблица отслеживания


13

В настоящее время я хочу структурировать таблицу отслеживания / истории следующим образом:

  • PrimaryKey - ID
  • OtherTableId - fk
  • fieldName - имя поля его отслеживания
  • OldValue
  • NewValue
  • UserName
  • CreateDateTime

Поэтому в основном я хочу иметь таблицу, которая будет отслеживать историю других таблиц, хранить имя столбца измененного поля с новым и старым значением. Мой вопрос: может ли кто-нибудь заделать дыры в этом? Кроме того, как проще всего убедиться, что в столбец fieldName заносится только имя столбца из отслеживаемых таблиц? В настоящее время я могу добавить перечисление в создаваемую мной службу или создать другую таблицу состояния и сделать fieldName fk. Есть идеи получше?

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

Благодарность!


Вы заранее знаете, сколько таблиц вы будете отслеживать?
Кофи Сарфо

Эта таблица будет отслеживать только одну другую таблицу, пока мы отслеживаем только эту одну таблицу.
user76982

Таким образом, этот подход может быть излишним. Еще хуже то, что тогда будет непросто запросить эту таблицу с отслеживаемой вместе, чтобы воссоздать живые данные в определенный момент времени, если воссоздание снимка будет иметь какое-либо значение.
Кофи Сарфо

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

Вы можете искать на dba.stackexchange.com ; там задавались похожие вопросы, и некоторые из них могут иметь ответы, которые вы можете использовать.
FrustratedWithFormsDesigner

Ответы:


8

Прощание: что, если схема базы данных будет изменена в тот же момент позже, и имя столбца изменится, или столбец будет удален полностью? Многие системы баз данных позволяют это. Что будет с вашим "fieldName"?

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

Если вы можете жить с решением, специфичным для поставщика БД: большинство систем БД имеют системные таблицы, в которых хранится информация о схеме (имена таблиц, идентификаторы таблиц, имена столбцов и т. Д.). Вы можете проверить, можно ли установить ссылку на внешний ключ для такой системной таблицы. Это позволило бы заменить имя поля идентификатором поля, если база данных поддерживает что-то вроде этого.

На самом деле, если вам нужно отслеживать целые строки конкретной таблицы, включая все столбцы (а не только небольшое подмножество столбцов), вы должны рассмотреть предложение @ sarfeast. Прочтите эту статью о недостатках моделей пары имя-значение.


8

Самая успешная реализация аудита изменений (отслеживания истории), которую я видел, менее универсальна и намного проще. Он включает создание таблицы журнала изменений для каждой таблицы, которую вы хотите отслеживать, сохраняя идентичные имена столбцов и типы данных (с дополнительным столбцом для отметки времени).

Конечная цель, то есть то, что вы хотели бы сделать с проверенными данными, поможет оценить, насколько подходящим может быть каждый подход.


Привет Sarfeast, я добавил конечную цель, которую я хочу достичь. Извините, что не включили это для начала.
user76982

Этот подход имеет свои недостатки. Читайте здесь: database-programmer.blogspot.co.uk/2008/07/history-tables.html
Туукка Хаапаниеми

7

Короче говоря: вам нужно установить механизм Audit Trail для таблиц, которые вы хотите отслеживать изменение значения.

Таблица единого контрольного журнала :

Создайте таблицу для регистрации имени таблицы, имени поля и старых и новых версий данных. Для этого метода обычно регистрируются как старые, так и новые версии данных и только те поля, которые изменились. Для реализации этого в триггерах необходимо, чтобы либо в таблице был первичный ключ, либо обновлялись только отдельные строки.

Вот хороший пост со сценариями о том, как этого добиться - Создание контрольных журналов

Другие полезные ссылки, чтобы посмотреть:


Вторая ссылка сейчас плохая.
Джереми Харрис

@cillosis, спасибо, что заметили это. Обновляется сейчас :)
Юсубов

3

Возможно, вы захотите проверить документацию проекта NHibernate Envers для идей.

По сути, у вас есть одна таблица редакций, в которую вы можете добавить дополнительные данные, такие как отметка времени или пользователь. Затем каждая отслеживаемая таблица получает дополнительную таблицу аудита со всеми дублированными столбцами, fk для таблицы редакций и тип редакции (добавить, изменить, удалить). AFAIK, вы бы не хотели, чтобы у ваших таблиц аудита был фактический FK к реальной таблице, потому что это предотвратит удаление.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.