Resposta direta
A ausência de histórico raramente é um problema de armazenamento. Ela é uma decisão de projeto: o campo foi sobrescrito, a data foi atualizada sem guardar a anterior, ou a alteração veio por importação que não gerou registro. O caminho é comparar o que o sistema grava hoje com o que a operação precisa saber depois — quem mudou, quando, de qual valor para qual valor e por qual origem. Onde esse rastro não existe, a alternativa é reconstruir por evidências indiretas, o que tem limite.
- Objetivo
- Diagnosticar
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Trata o histórico ausente como decisão de projeto e separa o que é reconstruível por evidência do que se perde de fato.
Onde o rastro se perde na rotina
A alteração que não deixa registro quase nunca é erro de quem digitou. Ela passa por um caminho que não grava: a tela sobrescreve o campo, a importação substitui a linha inteira, a integração envia o cadastro completo a cada rodada, ou a rotina agendada recalcula valores sem comparar com o anterior.
Em cada um desses casos, o valor final está correto e o passado desapareceu. Quem procura o histórico depois encontra apenas o estado atual. Sem a data anterior e o autor, a discussão vira memória contra memória.
O que conferir antes de dizer que não há registro
Antes de concluir que nada foi guardado, vale separar as fontes de evidência. Existe tabela de histórico ou log de auditoria, mesmo que ninguém consulte? A integração mantém arquivo de entrada e de saída? O backup guarda versões que permitem comparar duas datas?
Também importa o critério: para quais campos o rastro é necessário de verdade. Nem todo dado precisa de histórico. Limite de crédito, preço, responsável e situação cadastral costumam exigir. Descrição e observação, raramente. Definir isso evita construir controle para tudo.
O que a reconstrução não devolve
Reconstruir por comparação entre backups ou entre bases mostra que o valor mudou e, às vezes, quando. Raramente mostra quem mudou e por qual origem. Se duas pessoas tinham acesso ao mesmo campo no mesmo dia, a evidência indireta não decide.
Quando a alteração veio de importação sem arquivo de origem, nem o valor anterior se recupera. Nesse ponto o trabalho passa a ser ajustar o processo para frente: passar a registrar, definir quem responde pelo dado e aceitar que o período anterior fica sem rastro. Inventar o autor depois é pior que admitir a lacuna.
Recurso prático
Como rastrear onde a alteração deixa de ser registrada
- Escolher um campo sensível, como limite de crédito, preço ou responsável, e listar todas as origens que podem gravá-lo: tela, importação, integração e rotina agendada.
- Para cada origem, verificar o que fica gravado depois da mudança: valor anterior, valor novo, data, hora e autor.
- Provocar uma alteração de teste em ambiente controlado, por cada origem, e conferir se ela aparece no registro.
- Classificar o que sobrou: o que é reconstruível por log, arquivo de integração ou backup, e o que se perde sem volta.
O erro mais comum é testar pela tela, ver que o campo guarda data de modificação e concluir que o sistema registra histórico. Data de modificação não diz o que mudou nem quem mudou, e não cobre o que entra por importação ou integração direto na tabela.
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 alteração · log de auditoria · campo de data de modificação · usuário responsável pela mudança · carga de importaçã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
- Sistemas desconectados: métricas para dimensi… — sistemas desconectados
- Sistemas isolados: o que checar antes de comp… — sistemas desconectados
Páginas relacionadas
O mesmo problema em outro objetivo
- 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 precisa virar histórico — Orientar implementaçã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
- Cópias de base sem versão: alternativas para conciliação — Critérios para confrontar cópias de bases sem histórico de alteração, os métodos de comparação disponíveis e os limites operacionais de cada escolha.
- Dado sem histórico de origem: reconstruir o rastro mínimo — Reconstrução do rastro mínimo de um dado sem histórico de origem e definição do que passa a ser registrado em cada carga.
- Correção no banco de produção: registro e quem autoriza — Define quem autoriza, o que registrar e como o ajuste volta para a origem quando a correção é feita direto no banco de produção.
- Base de dados sem dono: o que comparar antes de decidir — Compara três arranjos para base sem dono definido: manter centralizado, nomear responsável ou dividir a guarda. Critérios, custos e limites de cada opção.
- 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.