Estratégia eficaz para deixar uma trilha de auditoria/histórico de alterações para aplicativos de banco de dados?

Question

Quais são algumas estratégias com as quais as pessoas tiveram sucesso para manter um histórico de alterações de dados em um banco de dados bastante complexo.Um dos aplicativos que utilizo e desenvolvo com frequência poderia realmente se beneficiar de uma forma mais abrangente de rastrear como os registros mudaram ao longo do tempo.Por exemplo, no momento os registros podem ter vários carimbos de data e hora e campos de usuário modificados, mas atualmente não temos um esquema para registrar múltiplas alterações, por exemplo, se uma operação for revertida.Em um mundo perfeito, seria possível reconstruir o registro como estava após cada salvamento, etc.

Algumas informações sobre o banco de dados:

• Precisa ter capacidade para crescer milhares de registros por semana
• 50-60 Mesas
• As principais tabelas revisadas podem ter vários milhões de registros cada
• Quantidade razoável de chaves estrangeiras e índices definidos
• Usando PostgreSQL 8.x

Answer 1

No passado, usei gatilhos para construir log de atualização/inserção/exclusão de banco de dados.

Você pode inserir um registro cada vez que uma das ações acima for executada em uma tabela específica em uma tabela de log que monitora a ação, qual usuário do banco de dados a fez, carimbo de data/hora, tabela em que foi executada e valor anterior.

Provavelmente há uma resposta melhor, pois isso exigiria que você armazenasse o valor em cache antes que a exclusão ou atualização real fosse realizada, eu acho.Mas você pode usar isso para fazer reversões.

Answer 2

Uma estratégia que você pode usar é MVCC, Multi-Value Concurrency Control.Neste esquema, você nunca faz atualizações em nenhuma de suas tabelas, apenas faz inserções, mantendo os números de versão de cada registro.Isso tem a vantagem de fornecer um instantâneo exato de qualquer momento e também evita completamente os problemas de bloqueio de atualização que afetam muitos bancos de dados.

Mas isso cria um banco de dados enorme e todas as seleções exigem uma cláusula extra para selecionar a versão atual de um registro.

Answer 3

Se você estiver usando o Hibernate, dê uma olhada em JBoss Envers.Na página inicial do projeto:

O projeto Envers visa permitir o fácil controle de versão de classes JPA persistentes.Tudo o que você precisa fazer é anotar sua classe persistente ou algumas de suas propriedades, que você deseja versionar, com @Versioned.Para cada entidade versionada será criada uma tabela que conterá o histórico de alterações realizadas na entidade.Você pode então recuperar e consultar dados históricos sem muito esforço.

Isto é um pouco semelhante a A abordagem de Eric, mas provavelmente com muito menos esforço.Não sei qual linguagem/tecnologia você usa para acessar o banco de dados.

Answer 4

O único problema com o uso de Triggers é que ele aumenta a sobrecarga de desempenho de qualquer inserção/atualização/exclusão.Para maior escalabilidade e desempenho, você gostaria de manter as transações do banco de dados no mínimo.A auditoria via gatilhos aumenta o tempo necessário para realizar a transação e dependendo do volume pode causar problemas de desempenho.

outra forma é explorar se o banco de dados fornece alguma forma de minerar os logs "Redo" como é o caso do Oracle.Redo logs é o que o banco de dados usa para recriar os dados caso ele falhe e precise se recuperar.

Answer 5

Semelhante a um gatilho (ou mesmo com), você pode fazer com que cada transação dispare um evento de registro de forma assíncrona e fazer com que outro processo (ou apenas thread) realmente lide com o registro.Haveria muitas maneiras de implementar isso, dependendo da sua aplicação.Sugiro que o aplicativo dispare o evento para que ele não cause carga desnecessária em sua primeira transação (o que às vezes leva a bloqueios de logs de auditoria em cascata).

Além disso, você poderá melhorar o desempenho do banco de dados primário mantendo o banco de dados de auditoria em um local separado.

Answer 6

Eu uso o SQL Server, não o PostgreSQL, então não tenho certeza se isso funcionará para você ou não, mas Pop Rivett publicou um ótimo artigo sobre como criar uma trilha de auditoria aqui:Perguntas frequentes nº 5 do SQL Server do Pop Rivett:Entre na trilha de auditoria

Crie uma tabela de auditoria e, em seguida, crie um gatilho para cada tabela que deseja auditar.

Dica:usar Codificador para construir seus gatilhos.