Отслеживание изменений данных

Question

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

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

Требуется выделить формы для просмотра / редактирования (скажем, синим), если конечный пользователь обновил определенное поле последним, или красным, если администратор «виноват».

Я ищу эффективный и последовательный метод для реализации этого.

Пока у меня есть следующие варианты:

• Для каждой записи в таблице T добавьте еще одну (char (1)), в которой пишите «U», если конечный пользователь вставил / обновил поле, или «A», если администратор сделал это. Когда визуализируется форма просмотра / редактирования, используйте эту информацию для выделения каждого поля соответствующим образом.

• Создайте новую таблицу H, хранящую историю редактирования, содержащую что-то вроде user_id, field_name, last_update_user_id. Держите таблицу H в актуальном состоянии, когда поля обновляются в основной таблице T. Когда визуализируется форма просмотра / редактирования, используйте эту информацию, чтобы соответствующим образом выделить каждое поле формы.

Каковы плюсы / минусы этих опций; Можете ли вы предложить другим?

Answer 1

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

Answer 2

Полагаю, это зависит только от того, насколько перспективным вы хотите быть.

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

Если вы выберете второй подход и сохраните более полную историю, если вам нужно добавить "«Редактировать историю», в будущем у вас уже будут все для этого настроено, и много данных ждет.Но если вам никогда не понадобятся эти данные, это пустая трата.

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

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

Answer 3

Лучший способ проверять изменения данных - использовать триггер в таблице базы данных. В вашем случае вы можете просто обновить последнего человека, чтобы внести изменения. Или вам может потребоваться полное решение для аудита, в котором вы сохраняете предыдущие значения, что позволяет легко восстановить их, если они были сделаны по ошибке. Но ключ к этому - делать это в базе данных, а не через приложение. Изменения в базе данных часто производятся не из приложения, а из других источников, и вы захотите узнать, произошло ли это также. Предположим, кто-то взломал базу данных и обновил данные, не хотите ли вы легко найти старые данные или узнать, кто это сделал, даже если он или она это делали через окно запроса, а не через приложение? Вам также может понадобиться узнать, были ли данные изменены с помощью импорта данных, если вам когда-либо понадобится получать большие объемы данных за один раз.