Resposta direta
O registro de alteração não se resolve com um campo de data. Ele exige definir quais campos têm consequência, guardar o valor anterior e o novo, identificar a origem da gravação e manter esse histórico fora do alcance de quem opera o dado. A escolha prática é capturar na camada que cobre toda gravação, inclusive rotinas automáticas e correções feitas direto no banco. Sem essa cobertura, o registro existe só para parte das mudanças e passa a dar falsa segurança. O escopo do que entra no histórico é decisão de negócio, não técnica.
- Objetivo
- Orientar implementação
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Trata a decisão de escopo do histórico, o ponto de captura e o custo de armazenamento que essa escolha cria.
O que o registro precisa responder
Um histórico útil responde quatro perguntas para cada mudança: qual registro mudou, qual campo mudou, qual era o valor anterior e quem ou o que gravou o valor novo, em que momento. Log técnico de erro não cobre isso. Ele mostra que a aplicação falhou, não que o limite de crédito saiu de um valor para outro.
A pergunta de negócio define o escopo. Campos que mudam por rotina, sem efeito sobre contrato, cobrança ou obrigação fiscal, raramente precisam de histórico. Campos que geram efeito financeiro, regulatório ou de responsabilidade precisam. Essa distinção é feita caso a caso, com as áreas que respondem pelo dado.
Onde a alteração é capturada
Há três pontos de captura: a camada de aplicação, o banco de dados e a comparação periódica entre cópias. A aplicação registra a intenção do usuário e costuma ser mais simples de manter, mas perde alterações feitas por script, carga em lote ou acesso direto ao banco. O banco cobre tudo que grava, inclusive rotinas automáticas, com custo de manutenção maior. A comparação periódica apenas indica que algo mudou entre duas datas, sem dizer o quê nem por quem.
A escolha depende de quem altera o dado fora da aplicação oficial. Enquanto houver correção manual, importação direta e rotina de terceiro, um registro apenas na aplicação deixa lacuna. Ordenar esse fluxo antes de escolher o ponto de captura evita refazer o trabalho depois.
Quando o histórico não resolve
Histórico não explica intenção. Ele mostra que o valor mudou e quem gravou, não se foi erro, ajuste autorizado ou fraude. Também não reconstrói o que passou antes de o registro entrar em operação: o período anterior permanece sem trilha, e essa ausência deve ser declarada, não preenchida por estimativa.
Registro não substitui controle de acesso nem conciliação entre sistemas. Se qualquer pessoa pode alterar o histórico, ele deixa de servir como prova. Retenção e exposição de dado pessoal dentro do histórico também pesam: guardar tudo por tempo indeterminado cria outro problema, de privacidade e de volume.
Recurso prático
Estimativa de volume do histórico de alterações
volume_anual_bytes = gravacoes_por_dia × campos_por_gravacao × dias_operados × bytes_por_campo
- gravacoes_por_dia
- gravações/dia
- número de gravações no sistema monitorado em um dia típico, contado no log da aplicação ou na estatística do banco
- campos_por_gravacao
- campos/gravação
- média de campos alterados em cada gravação, medida em uma amostra real do período, não estimada
- dias_operados
- dias/ano
- dias em que o sistema recebe gravação no ano, incluindo fins de semana quando houver operação
- bytes_por_campo
- bytes/campo
- tamanho de uma linha de histórico por campo alterado, com valor anterior, valor novo, autor e data
O ponto ignorado é o pico, não a média. Reprocessamento, importação em lote e correção em massa concentram a maior parte do histórico em poucos dias. Uma conta feita só com a média diária subestima o volume e o tempo de resposta da consulta ao histórico.
Conceitos usados nesta página
- Trilha de auditoria — Trilha de auditoria é o conjunto de registros que permite reconstruir quem fez o quê, quando e com qual dado — inclusive depois que o resultado já foi usado.
Sobre o que está escrito aqui
Conceitos relacionados: trilha de auditoria · valor anterior e valor novo · tabela de histórico · origem da gravação · política de retenção. Exemplos são ilustrativos. Não há cliente, resultado, preço, prazo ou certificação nesta página. Quando o formato indicado é Projeto de implementação, ele descreve uma possibilidade de trabalho — a conversa inicial avalia contexto e aderência.
Para continuar
- Integrações, sistemas e qualidade de dados — Página central do tema
- Planilha que virou sistema: como contratar a… — planilha que virou sistema paralelo
- Relatório manual mensal: onde procurar a caus… — relatório montado à mão todo mês
Páginas relacionadas
O mesmo problema em outro objetivo
- Alteração sem registro: onde o histórico se perde — Diagnosticar
- Alterações sem registro: o que passa a ser rastreável — Organizar um processo
- Histórico de alteração não registrado: alternativas possíveis — Comparar alternativas
- Histórico de alteração não registrado: como medir o tamanho — Explicar medição
- Alteração sem registro: o que ainda dá para reconstruir — Orientar avaliação e contratação
Outras leituras em Integrações, sistemas e qualidade de dados
- Registro excluído sem trilha: como implantar o rastro — O que definir para que exclusões deixem rastro: eventos a registrar, onde guardar o histórico, retenção e responsabilidade pelo acesso.
- Registro de alteração no cadastro: como comparar as formas — Compara quatro formas de registrar alteração no cadastro, o que cada uma prova, o que deixa em dúvida e onde o custo de manutenção aparece.
- Registro excluído sem trilha: o que reconstruir depois — Processo para lidar com exclusão sem histórico: o que reconstruir, quem responde e quais cadastros passam a exigir trilha.
- Sem identificador de execução: como a integração deixa rastro — O que registrar e como correlacionar uma integração sem identificador de execução, incluindo chave natural, janela de reconciliação e limites da abordagem.
- Exclusão sem trilha: o que exigir antes de contratar — O que um sistema precisa registrar em cada exclusão e o que o contrato deve cobrir antes da assinatura, incluindo acesso ao histórico.