django AuditTrail против реверсии

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

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

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

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

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

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

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

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

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

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

Так что я иду с AuditTrail.