É esta a melhor abordagem para a criação de uma trilha de auditoria?

Question

Eu estou tentando criar algumas funcionalidades que mantém uma trilha de auditoria de como dados em um determinado formulário de usuário foi alterado ao longo do tempo, com uma auditoria datado ao pé da página. Por exemplo:

02/04/09 21:49 Nome alterado de "Tom" para "Chris".

Estou fazendo isso por armazenar os dados em seu formato presente na sessão e, em seguida, em Save verificar se existem diferenças nos dados que estão sendo armazenados. Se houver, eu estou armazenando os dados como era antes da última edição em uma tabela chamada história, e armazenar os novos valores na tabela do usuário atual.

Esta é a melhor abordagem para tomar?

Answer 1

Uma sugestão; isso seria relativamente fácil de fazer em um gatilho de banco de dados. Nesse caso, você nunca tem que se preocupar se o código executando a atualização lembra para adicionar um registo histórico.

Answer 2

Eu não tenho certeza há uma "melhor abordagem", existem muitas variáveis ??a ter em consideração, incluindo o quão longe no caminho de desenvolvimento que você está.

Tendo sido através de ambas as soluções de auditoria baseada em código e db-gatilho, listei alguns comentários abaixo; Espero que você possa ver onde você está agora em (em termos de desenvolvimento) poderia afetar estas questões:

• Se você precisa mapear o usuário que alterou os dados (que você normalmente faz), então gatilhos db terá de obter essa informação de alguma forma. Não é impossível, mas mais trabalho e várias maneiras de abordar este (usuário db consulta em execução, coluna utilizador comum em cada mesa, etc.)
• Se você usar gatilhos db e você confiar em linhas afetadas contagem retornadas de consultas, em seguida, seus gatilhos de auditoria precisa ter esta desligado, ou o seu código existente modificado para conta para eles.
• gatilhos IMHO db oferecer mais segurança e oferecer um caminho mais fácil para automação de auditoria, porém eles não são infalíveis, como qualquer pessoa com acesso adequado pode desativar os gatilhos, modificar dados e, em seguida, permitir-lhes novamente. Em outras palavras, garantir que seus direitos de acesso de segurança db estão apertados.
• Ter uma única mesa para a história não é um mau caminho a percorrer, embora você terá mais trabalho a fazer (e dados para loja) se você é história auditoria para várias tabelas, especialmente quando se trata de reconstruir a trilha de auditoria. Você também tem que considerar as questões de bloqueio se houver muitas tabelas tentar escrever uma tabela de auditoria.
• Ter uma tabela de histórico de auditoria para cada mesa é outra opção. Você só precisa de cada coluna na tabela de auditoria a ser anulável, bem como data e hora da ação armazenamento (insert / update / delete) e o usuário associado com a ação.
• Se você vai com a opção de tabela única, a menos que você tem um monte de tempo para gastar com isso, não fique muito extravagante tentando auditoria apenas em atualizações ou exclusões, embora possa ser tentador para evitar inserções (já que a maioria Aplicativos fazer isso mais vezes do que as atualizações ou exclusões), reconstruir a história de auditoria leva um pouco de trabalho.
• Se os seus servidores ou dados abranger vários fusos horários, em seguida, considerar o uso de um tipo de data e hora apropriada para ser capaz de armazenar e reconstruir a linha do tempo, ou seja, armazenar data do evento auditoria em UTC, bem como incluindo o deslocamento de fuso horário.
• Estas tabelas de auditoria pode obter enorme, por isso têm uma estratégia, se eles começam a afetar o desempenho. As opções incluem particionamento de tabela em discos diferentes, arquivar, etc. basicamente pensar sobre isso agora e não quando ele se torna um problema:)

Answer 3

Eu sempre fui um fã de usar uma tabela em vez de quebrá-lo em uma tabela "ativa" e uma tabela "história". I colocar 4 colunas nestas tabelas, todas as marcas de tempo: criados, apagados, início, fim. "Criado" e "excluídos" são bastante auto-explicativo. Os "Iniciar" e timestamps "finais" são para quando o registro foi realmente o registro "ativo". O registro ativo teria um "start" tempo antes now() e uma NULL tempo "fim". Ao separar os "criados" e "Iniciar" vezes, você pode programar mudanças ocorram no futuro.

Este projeto, ao contrário do design de dois mesa, permite consultas facilmente escrever que irão operar automaticamente os dados certos. Suponha que sua tabela é armazenar a taxa de imposto ao longo do tempo ... você não quer ter todas as suas dúvidas de que as taxas de imposto uso em seus cálculos têm a complexidade extra de decidir a procurar coisas para cima em uma tabela de histórico ao processar faturas antigas, por exemplo ... você pode simplesmente olhar para cima a taxa de imposto em vigor no momento da fatura foi criado em uma consulta, independentemente de saber se é a taxa de imposto atual ou não.

Esta ideia não é originalmente minha (embora eu fiz re-inventar a idéia aproximada em meu próprio antes de ler sobre isso) ... você pode encontrar uma discussão detalhada sobre isso neste on-line livro .

Answer 4

O envolvimento sessão faz-me um pouco cauteloso (Você tem certeza que você está lidando com isso corretamente quando dois usuários estão trabalhando nos mesmos dados ao mesmo tempo?), Mas, em geral, sim, manter uma tabela de histórico é o direito coisa.

Answer 5

Eu também pensaria sobre um gatilho de banco de dados na inserção ou atualização para registrar detalhes de mudança (quem, quando, o quê, valor antes, valor depois) a uma tabela de auditoria separado. Dessa forma, você sabe que, mesmo se os dados forem alterados outide de seu aplicativo usando o banco de dados diretamente, ele ainda vai ser pego.

Você também pode querer fazer algo para detectar se os dados forem alterados outide do seu aplicativo, como calcular um hash ou CRC do registro e armazená-lo em um lugar de campo, em seguida, verificar que ao ler os dados.

Answer 6

Eu acho que sua proposta envolveria escrevendo um monte de código / metadados para permitir a comparação de objetos / registros de modo a obter uma auditoria de nível de negócios.

Como alternativa, um gatilho de banco de dados não pode dar-lhe uma visão de alto-suficiente nível do que aconteceu. Isso pode ser aceitável se você usar a auditoria tão raramente que o esforço de recriar o significado de negócios é ok.

Isso também parece ser uma boa aplicação para AOP (Aspectos), onde você poderia usar reflexão sobre o modelo de objeto para despejo algo significativo sem a necessidade de uma grande quantidade de metadados.