Существует ли лучшая практика для поддержания истории в базе данных?
Я не делаю работы базы данных, что часто, таким образом, это - полностью незнакомая территория для меня.
У меня есть таблица с набором записей, которые могут обновить пользователи. Однако я теперь хочу сохранить историю их изменений на всякий случай, они хотят откатывать. Откат в этом случае не является откатом дб, но больше как возвращаются, изменяется две недели спустя, когда они поняли, что сделали ошибку. Так как различие - это, у меня не может быть транзакции, делают задание.
Существующая практика должна использовать отдельную таблицу или просто флаг в текущей таблице?
Это - маленькая база данных, 5 таблиц каждый с <6 столбцов, <1 000 общих количеств строк.
5 ответов
Разочарованный ответ - одно решение, другое - таблица аудита, в которой записываются изменения, когда и кем. Это действительно вопрос подхода. Если производительность таблиц вашего приложения имеет решающее значение, и они могут значительно вырасти с использованием подхода «активной строки», тогда таблица аудита лучше, поскольку она отделяет историю от активного материала (и я надеюсь, что исправление ошибок пользователя будет меньше обычные, чем «обычные» транзакции).
ОТ ЭТОГО ВОПРОСА
Как сохранить историю обновлений записей в MySQL?
Один простой способ сохранить историю версий - создать практически идентичную таблицу (например, с суффиксом _version). Обе таблицы будут иметь поле версии, которое для основной таблицы вы увеличиваете при каждом обновлении. Таблица версий будет иметь составной первичный ключ на (id, version).
Всякий раз, когда вы обновляете фактическую таблицу, вы также вставляете новую строку в таблицу версий с дублирующими данными. Когда вы хотите найти историю версий, все, что вам нужно сделать, это что-то вроде SELECT * FROM content_version WHERE id = CONTENT_ID ORDER BY version.
Если вы используете что-то вроде Doctrine ORM, у него есть поведение, которое делает это для вас автоматически через слушателей событий. Вы можете проверить это здесь: http://www.doctrine-project.org/documentation/manual/1_2/en/behaviors#core-behaviors:versionable
OR
Самым простым решением (в зависимости от ваших конкретных потребностей), вероятно, будет добавить триггер на обновление/вставку/удаление в вашу таблицу, чтобы вы могли выполнять дополнительное протоколирование, когда данные вставляются/обновляются/удаляются. Таким образом, даже ручное вмешательство в БД будет покрыто...
Проверьте http://dev.mysql.com/doc/refman/5.1/en/triggers.html для получения дополнительной информации.
Я бы рекомендовал вторую таблицу. Очень простым и легким способом будет дублирование схемы каждой таблицы и столбца "Date/Time Stamp" и столбца "ModifiedByUserID", которые будут хранить исходные данные.
В качестве альтернативы, если пользователи не изменяют много записей в одной строке за один раз, вы можете сэкономить место и получить лучшее представление о происходящем, сделав схему ниже:
ChangesTable
ChangeID
[TABLE UNIQUE ID]
UserName
Field
OldValue
NewValue
CreatedDate
Вы можете использовать временную метку, чтобы указать, когда была создана запись, и индикатор состояния, чтобы указать, является ли запись «Активной» или нет.
Когда они обновляют запись, вставляют ее копию как новую запись (триггеры могут сохранять текущие отметки времени), а затем устанавливают статус старой записи на «Архив», а для новой - на «Активная». При желании вы также можете иметь другие поля аудита, такие как «Отметка времени последнего обновления», «Дата архивации», «Дата разархивирования» (для отката), «Создано пользователем», «Последнее изменение пользователем», .. • Если вам нужна полная история аудита, вам понадобится отдельная таблица аудита.
Откат - это просто выбор версии и отметка ее как «Активная», а для остальных - как «Архивная».
Существуют и другие схемы, более гибкие, но также более сложные, но они могут вам не понадобиться.
Один из вариантов - сделать так, чтобы все ваши таблицы содержали столбец ID и столбец VersionNo. Затем вместо запуска ОБНОВЛЕНИЙ вы вставляете новую запись с тем же идентификатором и увеличенным номером версии.
Затем вы можете создать несколько представлений для каждой таблицы, которые возвращают только последнюю версию каждого идентификатора, чтобы упростить управление вашими запросами.