Django AuditTrail vs Reversão

Question

Eu estou trabalhando em um novo aplicativo web eu preciso para armazenar quaisquer alterações na base de dados para a tabela de auditoria (s). Propósito de tais tabelas de auditoria é que, mais tarde, em uma auditoria físico real podemos asecertain o que aconteceu em uma situação, que editou o que e qual era o estado de db no momento do exemplo um cálculo complexo. Então, na sua maioria tabela de auditoria será escrito e não ler. Relatório pode ser gerado embora às vezes.

Eu olhei para solução disponível

1. AuditTrail - simples e que é por isso que estou inclinando em direção a ela, eu posso entendê-lo código único arquivo.
2. Reversão - parece bastante simples de usar, mas não sei como seria fácil para modificar -lo se necessário.
3. rcsField parece ser muito complexo e muito para as minhas necessidades

Eu não tentei qualquer um deles, então eu queria saber algumas experiências reais e que eu deveria estar usando. por exemplo. qual é o mais rápido usa menos espaço, fácil de estender e manter?

Answer 1

Como afirmei na minha pergunta rcField parece ser muito para as minhas necessidades, o que é simples que eu quero armazenar quaisquer alterações à minha mesa, e pode ser voltar mais tarde para essas mudanças para gerar alguns relatórios.

Então, eu testei AuditTrail e Reversão Reversão parece ser uma aplicação soprado melhor cheia com muitos recursos (que eu não preciso), também, tanto quanto eu sei que salva os dados em uma única tabela em formato YAML ou XML, o que eu acho

1. irá gerar muitos dados em uma tabela única
2. para ler esses dados não podem ser capazes de usar já presente ferramentas db.

AuditTrail ganha a este respeito que, para cada tabela que gera uma tabela de auditoria correspondente e, por conseguinte, as alterações podem ser facilmente rastreados, por dados de tabela é menor e pode ser facilmente manipulada e de usuário para a geração de relatórios.

Então, eu estou indo com AuditTrail.

Answer 2

Pessoalmente eu prefiro para criar tabelas de auditoria no banco de dados e preencher através de gatilhos de modo que qualquer mudança, mesmo hoc queries ad partir da janela de consulta são armazenados. Eu nunca iria considerar uma solução de auditoria que não se baseia no próprio banco de dados. Isto é importante porque as pessoas que estão fazendo alterações maliciosas ao banco de dados ou cometer fraudes não são susceptíveis de fazê-lo através da interface web, mas no backend diretamente. Muito mais dessas coisas acontece de funcionários descontentes ou larcenous que hackers externos. Se você estiver usando um ORM já, seus dados estão em risco, porque as permissões estão no nível de tabela em vez do nível sp onde eles pertencem. Por isso, é ainda mais importante que você capturar qualquer possível mudança para a dat não apenas o que foi a partir da GUI. Temos um proc dinâmica para criar tabelas de auditoria que é executado sempre que novas tabelas são adicionadas ao banco de dados. Desde nossas mesas de auditoria preencher apenas as alterações e não todo o registro, nós não precisamos mudá-los cada vez que um campo é adicionado.

Além disso, quando avaliar possíveis soluções, certifique-se considerar o quão difícil será para reverter os dados para desfazer uma alteração específica. Depois de ter tabelas de auditoria, você vai achar que esta é uma das coisas mais importantes que você precisa fazer a partir deles. Considere também o quão difícil será para maintian a informação como as alterações de esquema de banco de dados.

Escolhendo uma solução porque parece ser o mais fácil de entender, não é geralmente uma boa idéia. Isso deve ser menor de seus critérios selction depois que cumpram os requisitos, segurança, etc.

Answer 3

Eu não posso dar-lhe experiência real com qualquer um deles, mas gostaria de fazer uma observação.

Eu assumo por AuditTrail você quer dizer AuditTrail no Django wiki . Se assim for, eu acho que você vai querer olhar em vez de HistoricalRecords desenvolvido pelo mesmo autor (Marty Alchin aka @gulopine) em seu livro Pro Django . Ele deve funcionar melhor com Django 1.x.

Esta é a abordagem que eu vou estar usando em um próximo projeto, não porque necessariamente bate os outros a partir de um ponto de vista técnico, mas porque ele corresponde às expectativas "mundo real" da trilha de auditoria para essa aplicação.