В настоящее время я хочу структурировать таблицу отслеживания / истории следующим образом:
- PrimaryKey - ID
- OtherTableId - fk
- fieldName - имя поля его отслеживания
- OldValue
- NewValue
- UserName
- CreateDateTime
Поэтому в основном я хочу иметь таблицу, которая будет отслеживать историю других таблиц, хранить имя столбца измененного поля с новым и старым значением. Мой вопрос: может ли кто-нибудь заделать дыры в этом? Кроме того, как проще всего убедиться, что в столбец fieldName заносится только имя столбца из отслеживаемых таблиц? В настоящее время я могу добавить перечисление в создаваемую мной службу или создать другую таблицу состояния и сделать fieldName fk. Есть идеи получше?
Изменить цель: в настоящее время есть только 2 поля, которые мы хотим отслеживать. Одно поле будет отображаться на веб-странице для отображения истории, другое поле будет доступно только одному отделу, и у них есть доступ к представлению базы данных, к которому они смогут обращаться. Они будут запрашивать только это одно поле, чтобы получить информацию о том, кто изменил поле и на что. По этой причине мы хотели установить его там, где поле базы данных определяет столбец таблицы, а не имеет точную копию истории записей таблицы. Мы хотим, чтобы только два поля отслеживались с возможностью добавления или удаления полей в будущем.
Благодарность!
Ответы:
Прощание: что, если схема базы данных будет изменена в тот же момент позже, и имя столбца изменится, или столбец будет удален полностью? Многие системы баз данных позволяют это. Что будет с вашим "fieldName"?
Для обеспечения целостности данных: вы должны убедиться, что каждая операция обновления или удаления обязательно обновит вашу таблицу отслеживания. Это лучше всего достигается с помощью триггеров, вызывающих хранимую процедуру. Вы должны убедиться, что только те хранимые процедуры имеют доступ для записи в вашу таблицу отслеживания, чтобы никто другой не мог записать неправильные значения.
Если вы можете жить с решением, специфичным для поставщика БД: большинство систем БД имеют системные таблицы, в которых хранится информация о схеме (имена таблиц, идентификаторы таблиц, имена столбцов и т. Д.). Вы можете проверить, можно ли установить ссылку на внешний ключ для такой системной таблицы. Это позволило бы заменить имя поля идентификатором поля, если база данных поддерживает что-то вроде этого.
На самом деле, если вам нужно отслеживать целые строки конкретной таблицы, включая все столбцы (а не только небольшое подмножество столбцов), вы должны рассмотреть предложение @ sarfeast. Прочтите эту статью о недостатках моделей пары имя-значение.
источник
Самая успешная реализация аудита изменений (отслеживания истории), которую я видел, менее универсальна и намного проще. Он включает создание таблицы журнала изменений для каждой таблицы, которую вы хотите отслеживать, сохраняя идентичные имена столбцов и типы данных (с дополнительным столбцом для отметки времени).
Конечная цель, то есть то, что вы хотели бы сделать с проверенными данными, поможет оценить, насколько подходящим может быть каждый подход.
источник
Короче говоря: вам нужно установить механизм Audit Trail для таблиц, которые вы хотите отслеживать изменение значения.
Таблица единого контрольного журнала :
Вот хороший пост со сценариями о том, как этого добиться - Создание контрольных журналов
Другие полезные ссылки, чтобы посмотреть:
источник
Возможно, вы захотите проверить документацию проекта NHibernate Envers для идей.
По сути, у вас есть одна таблица редакций, в которую вы можете добавить дополнительные данные, такие как отметка времени или пользователь. Затем каждая отслеживаемая таблица получает дополнительную таблицу аудита со всеми дублированными столбцами, fk для таблицы редакций и тип редакции (добавить, изменить, удалить). AFAIK, вы бы не хотели, чтобы у ваших таблиц аудита был фактический FK к реальной таблице, потому что это предотвратит удаление.
источник