Как мне использовать контрольный журнал, чтобы отобразить, какие поля когда-либо редактировались?

Question

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

Приложение будет разработано на PHP/MSSQL и будет иметь низкий трафик.

Прочитав, я в значительной степени решил создать таблицу аудита и использовать триггеры для записи изменений в таблице.

Два требования к отображению в приложении следующие:

1. Уметь видеть журнал всех изменений, внесенных в поле (я почти знаю, как это сделать).

2. Возможность видеть при просмотре записи в приложении индикатор рядом с любым полем записи, которое когда-либо менялось (и, возможно, другую информацию, например дату последнего изменения).

Пункт №2 меня сейчас огорчает.Не выполняя отдельный запрос для каждого поля (или очень длинный вложенный запрос, выполнение которого займет много времени), есть ли у кого-нибудь предложения по оптимальному способу сделать это?(Я подумал о добавлении дополнительного поля «ModifiedFlag» для каждого поля в таблице, которое будет действовать как логический индикатор, если поле когда-либо редактировалось, но это похоже на большие накладные расходы.

Answer 1

Я бы рассматривал информацию аудита отдельно от фактической информации о домене, насколько это возможно.

Требование №1:Я думаю, вы создадите дополнительные таблицы аудита для записи изменений.Предложение Эрика является хорошим: создание информации аудита с использованием триггеров в базе данных SQL.Таким образом, вашему приложению не нужно знать о логике аудита.

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

Требование №2:Что касается отображения показателей:Я бы не стал создавать логические поля в таблице, в которой хранятся фактические значения.(Это приведет к возникновению всевозможных зависимостей между вашими нормальный код приложения и ваш аудиторский след код.)

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

Некоторые большие приложения Enterpriserisy, которые я поддерживаю, используют примерно следующую структуру:

• Таблица заголовков изменений, соответствующая изменению записи в таблице.

Поля:

changeId, changeTable, changedPrimaryKey, userName, dateTime

- Таблица полей изменений, соответствующая изменяемому полю.

Поля:

changeId, changeField, oldValue, NewValue

Пример содержимого:

Изменть Заголовок:

'1', 'BooksTable', '1852860138', 'AdamsD', '2009-07-01 15:30'

Изменить элемент:

'1', 'Title', 'The Hitchhiker's Guide to the Gaxaly', 'The Hitchhiker's Guide to the Galaxy'
'1', 'Author', 'Duglas Adasm', 'Douglas Adams'

Эта структура позволяет как легко просматривать журналы аудита, так и легко находить нужные показатели.Одного запроса (внутреннего соединения в таблице «Заголовок» и «Элементы») было бы достаточно, чтобы получить всю информацию и отобразить ее в одной форме.(Или даже таблицу, если у вас есть список отображаемых идентификаторов)

Answer 2

Как общее требование, пометка измененного поля «пахнет» немного странно.Если записи долгоживущие и могут со временем меняться, то в конечном итоге все поля будут помечены таким флагом.Поэтому мне интересно, как любой пользователь может понять простой набор индикаторов для каждого поля.

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

Я думаю, что ваша идея подготовить какие-то данныеагрегатаOfTheAuditTrail, вероятно, будет очень полезной.Вопрос в том, достаточно ли одного флага для каждой записи?Если основной доступ пользователя осуществляется через список, то, возможно, достаточно просто выделить измененные записи для последующего просмотра.Или дату последнего изменения значения записи, чтобы были выделены только недавно измененные записи – все это соответствует реальным потребностям пользователя.Мне сложно представить, что записи, изменённые 3 года назад, так же интересны, как и изменённые на прошлой неделе.

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

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

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

Answer 3

Лично я бы сделал отслеживание простым, а отчетность интересной.

Каждый раз, когда пользователь вставляет запись, вы делаете вставку в таблицу аудита для этой таблицы.

'I', 'Date', 'User', 'Data column1','Data Column2', etc.

Это при условии, что структура таблиц не изменится со временем (т.количество столбцов данных)

Для получения обновлений просто вставьте

'U', 'Date', 'User', 'Data column1', etc

Вставьте то, что пользователь только что ввел в качестве обновления.

Тогда после вставки и обновления у вас будет следующее

'I','May 3 2009','BLT','person005','John','Smith','Marketing'
'U','May 4 2009','BLT','person005','John','Smith','Accounting'

Тогда это просто отчет, показывающий, что уникальная запись о человеке «person005» имела вставку и обновление, в котором был обновлен их отдел.

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