Джанго AuditTrail против реверсии

Question

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

Я искал доступное решение

<Ол>

AuditTrail - просто, и поэтому я склоняюсь к этому, я могу это понять код одного файла.

Reversion - выглядит достаточно простым в использовании, но не уверен, насколько легко было бы изменить это при необходимости.

rcsField кажется очень сложным и слишком большим для моих нужд

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

Answer 1

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

Итак, я протестировал AuditTrail и Reversion Реверсия кажется лучшим полнофункциональным приложением со множеством функций (которые мне не нужны). Кроме того, насколько я знаю, она сохраняет данные в одной таблице в формате XML или YAML, что, я думаю,

<Ол>

создаст слишком много данных в одной таблице

для чтения этих данных я не смогу использовать уже имеющиеся инструменты БД.

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

Так что я собираюсь с AuditTrail.

Answer 2

Лично я предпочитаю создавать контрольные таблицы в базе данных и заполнять триггеры, чтобы сохранять любые изменения, даже специальные запросы из окна запроса. Я бы никогда не подумал о решении для аудита, которое не основано на самой базе данных. Это важно, потому что люди, которые вносят злонамеренные изменения в базу данных или совершают мошенничество, вряд ли будут делать это через веб-интерфейс, а напрямую через бэкэнд. Гораздо больше всего этого происходит от недовольных или воровавших сотрудников, чем от внешних хакеров. Если вы уже используете ORM, ваши данные находятся под угрозой, потому что разрешения находятся на уровне таблицы, а не на уровне sp, к которому они принадлежат. Поэтому еще более важно, чтобы вы зафиксировали любое возможное изменение данных, а не только то, что было из GUI. У нас есть динамический процесс создания таблиц аудита, который запускается при добавлении новых таблиц в базу данных. Поскольку наши таблицы аудита заполняют только изменения, а не всю запись, нам не нужно менять их каждый раз при добавлении поля.

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

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

Answer 3

Я не могу дать вам реальный опыт с любым из них, но хотел бы сделать замечание.

Я предполагаю, что под AuditTrail вы имеете в виду AuditTrail в вики Django . Если это так, я думаю, что вместо этого вы захотите взглянуть на HistoricalRecords , разработанную тем же автором (Марти Алчин aka @gulopine) в его книге Pro Django . Это должно работать лучше с Django 1.x.

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