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

13

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

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

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

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

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

database sql tracking

— user76982
источник

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

— Кофи Сарфо

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

— 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 к реальной таблице, потому что это предотвратит удаление.

— dotjoe
источник