Вопрос по php, sql-server – Как бы я использовал контрольный журнал для отображения, какие поля когда-либо редактировались?

7

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

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

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

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

  1. Be able to see a log of all changes made to a field (I pretty much know how to do this)

  2. Be able to see, when viewing a record in the application, an indicator next to any field in the record that has ever been changed (and possibly other info like the date of the last change).

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

Ваш Ответ

3   ответа
4

о домене в максимально возможной степени.

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

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

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

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

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

A change header table corresponding to a change of a record in a table.

Поля:

changeId, changeTable, changedPrimaryKey, userName, dateTime

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

Поля:

changeId, changeField, oldValue, NewValue

Sample content:

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

'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'

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

Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded Kirsehn
Error: User Rate Limit Exceeded Kirsehn
0

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

'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'

Затем это просто простой отчет, показывающий, что уникальный человек записывает "персона 005". была вставка и обновление, где их отдел был обновлен.

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

2

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

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

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

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

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

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

Error: User Rate Limit Exceeded Kirsehn

Похожие вопросы