Resposta direta
Corrigir direto no banco de produção é aceitável quando a alteração é pontual, reversível e registrada, e quando a origem do erro já foi tratada. A comparação prática se faz por três eixos: tempo de execução, quem assume a responsabilidade pelo que for alterado e o que acontece se o mesmo dado voltar errado. Edição manual serve para poucos registros e efeito imediato. Script versionado serve quando a correção se repete e precisa de revisão. Correção na origem serve quando o erro se reproduz. Sem registro e sem dono, qualquer uma delas vira dívida.
- Objetivo
- Comparar alternativas
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Coloca as formas de corrigir um dado lado a lado pelo que cada uma exige em responsabilidade, registro e reversibilidade, em vez de discutir qual ferramenta usar.
Três caminhos e o que cada um cobra
A edição direta no banco tem custo baixo de execução e custo alto de rastreabilidade. Resolve o registro visível agora e não deixa trilha se o registro não for feito em separado. Serve para casos isolados, com volume pequeno e efeito que não precisa ser repetido.
O script versionado troca velocidade por controle. Passa por revisão, fica guardado com data e autor e pode ser reaplicado. Custa mais tempo na primeira vez e menos em cada repetição. É o caminho natural quando a mesma correção já foi feita mais de uma vez.
A correção na origem ataca a regra que gerou o dado errado. Demora mais para aparecer, porque depende de mudança em sistema ou processo, e é a única que reduz a chance de o erro voltar. Custa desenvolvimento e negociação entre áreas.
O que decidir antes de escolher
A escolha começa pela responsabilidade: quem responde pelo dado depois da correção. Se a resposta for da área que corrigiu, o registro tem que existir. Se for da área de origem, ela precisa ser avisada antes, não depois.
O segundo critério é reversibilidade. Uma correção que sobrescreve valor sem cópia do anterior não pode ser desfeita. Guardar o estado anterior é parte do procedimento, não um detalhe.
O terceiro é o sinal de problema estrutural: se o dado volta errado na carga seguinte, a discussão deixa de ser qual correção aplicar e passa a ser qual regra mudar.
O que a correção direta não resolve
Corrigir o banco não conserta a integração que produziu o erro. O dado fica correto por um tempo e volta a divergir se a origem continuar gerando o mesmo valor. A comparação de caminhos não substitui o trabalho de encontrar a causa.
Também não se aplica quando o volume é alto ou quando o valor corrigido alimenta cálculo já fechado, como faturamento, imposto ou comissão. Nesses casos a alteração mexe em número já reportado, e o critério passa a ser outro, com aprovação de quem responde pelo resultado.
Nenhum caminho de correção dispensa registro. A opção mais simples e a mais elaborada falham do mesmo jeito quando ninguém sabe o que foi alterado.
Recurso prático
Da correção pontual à decisão sobre a origem
- Descrever a correção em uma linha: qual tabela, quais registros, qual valor sai, qual valor entra e o critério que identifica esses registros.
- Registrar quem aprova, quem executa e onde a alteração fica documentada, com data e motivo.
- Conferir o resultado com a mesma consulta de seleção usada antes da correção, comparando a contagem de registros e o valor final.
- Classificar a origem: se o dado volta errado na próxima carga, a correção no banco foi paliativo e a regra de entrada precisa ser revista.
O erro mais comum é aprovar a correção olhando só o registro que apareceu na tela. Sem a consulta que seleciona todos os registros afetados, ninguém sabe o tamanho real do conjunto nem se a alteração atingiu linhas além das previstas.
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: banco de produção · script de correção · trilha de auditoria · janela de manutenção · carga de dados. 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
- Números que não batem: por que a divergência… — planilhas divergentes
- Sincronização entre sistemas: o que decidir a… — sistemas desconectados
Páginas relacionadas
O mesmo problema em outro objetivo
- Correção direta no banco de produção: o rastro que falta — Diagnosticar
- Correção no banco de produção: registro e quem autoriza — Organizar um processo
- Correção direta no banco de produção: o que medir — Explicar medição
- Correção direta no banco de produção: o que combinar antes — Orientar avaliação e contratação
Outras leituras em Integrações, sistemas e qualidade de dados
- Log de integração sem nível de erro: o que exigir no contrato — Contrato de log de integração: níveis de severidade, campos obrigatórios, retenção, responsabilidade e teste de aceite com falha provocada.
- Cópia de segurança sem teste de leitura: o que medir — Medição de cópia de segurança por teste de leitura: o que registrar antes, durante e depois da restauração, e o que o registro não prova.
- 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.
- Erro descoberto pelo cliente: o que avaliar antes de contratar — O que avaliar e o que deixar definido no contrato quando o cliente descobre um erro de sincronização. Responsabilidade, evidência e correção.
- Horário sem fuso: como comparar registros entre sistemas — Compara as formas de tratar horários sem fuso declarado e mostra o custo de cada escolha em junção, relatório e auditoria.