Não tenho certeza se existe uma "melhor abordagem", há tantas variáveis ​​a serem levadas em consideração, incluindo o quão longe você está no caminho de desenvolvimento.

Tendo passado por soluções de auditoria baseadas em código e db-trigger, listei alguns comentários abaixo; Espero que você possa ver onde você está agora (em termos de desenvolvimento) pode afetar esses problemas:

• Se você precisar mapear o usuário que alterou os dados (o que você normalmente faz), os gatilhos db precisarão obter essas informações de alguma forma. Não é impossível, mas mais trabalho e várias maneiras de abordar isso (usuário de banco de dados executando consulta, coluna de usuário comum em cada tabela etc.)
• Se você usa acionadores de banco de dados e confia na contagem de linhas afetadas retornada de consultas, seus acionadores de auditoria precisam estar desativados ou seu código existente modificado para considerá-los.
• Os gatilhos de banco de dados IMHO oferecem mais segurança e oferecem um caminho mais fácil para a automação de auditoria, mas não são infalíveis, pois qualquer pessoa com acesso apropriado pode desabilitar os gatilhos, modificar dados e ativá-los novamente. Em outras palavras, certifique-se de que seus direitos de acesso de segurança de banco de dados sejam rígidos.
• Ter uma única tabela para o histórico não é um mau caminho, embora você tenha mais trabalho a fazer (e dados para armazenar) se estiver auditando o histórico de várias tabelas, especialmente quando se trata de reconstruir a trilha de auditoria. Você também deve considerar problemas de bloqueio se houver muitas tabelas tentando gravar em uma tabela de auditoria.
• Ter uma tabela de histórico de auditoria para cada tabela é outra opção. Você só precisa que cada coluna na tabela de auditoria seja anulável, além de armazenar a data e hora da ação (inserir/atualizar/excluir) e o usuário associado à ação.
• Se você optar pela opção de tabela única, a menos que tenha muito tempo para gastar com isso, não se arrisque tentando auditar apenas atualizações ou exclusões, embora possa ser tentador evitar inserções (já que a maioria apps fazem isso com mais frequência do que atualizações ou exclusões), a reconstrução do histórico de auditoria exige bastante trabalho.
• Se seus servidores ou dados abrangerem vários fusos horários, considere usar um tipo de data e hora apropriado para poder armazenar e reconstruir a linha do tempo, ou seja, armazenar a data do evento de auditoria em UTC e incluir o deslocamento do fuso horário.
• Essas tabelas de auditoria podem ficar enormes, então tenha uma estratégia se elas começarem a afetar o desempenho. As opções incluem particionamento de tabelas em diferentes discos, arquivamento, etc. basicamente pense nisso agora e não quando se tornar um problema :)