Do Google Sheets ao SQL: quando o fluxo de relatórios amadurece

Troque copiar e colar por um pipeline rastreável

Antes de desenhar tabelas, entenda o papel da planilha: fonte oficial, fila de revisão, exportação temporária ou relatório anotado pelas equipes? Não elimine uma aprovação humana só porque o SQL consegue armazenar as linhas. Mantenha etapas de revisão deliberadas quando elas evitam decisões erradas sobre finanças, estoque ou clientes.

Modele o processo antes das tabelas

Importe os dados brutos antes de tratá-los

Guarde um lote imutável com planilha e intervalo de origem, horário da extração, revisão disponível, identidade do serviço e identificador da execução. Preserve os valores brutos ou uma cópia fiel separada dos registros normalizados. Assim é possível reproduzir um relatório, explicar uma rejeição e executar novamente validações melhores sem fingir que a entrada original já estava limpa.

Leia apenas intervalos aprovados, agrupe leituras pela API e use a identidade e as permissões mínimas necessárias. Nunca deixe uma credencial duradoura em uma planilha compartilhada ou script de navegador. Trate fórmulas, datas sujeitas à localidade, células vazias e números que na verdade são identificadores como casos diferentes.

Valide em camadas e explique as rejeições

Normalize tipos e fusos horários; depois confira campos obrigatórios, valores permitidos, unicidade, integridade referencial e regras do negócio. Rejeite ou coloque em quarentena registros inválidos com um código estável e referência à linha de origem. Não converta silenciosamente “1.234,50” usando a localidade errada nem remova zeros à esquerda de códigos de clientes ou produtos. A correção autorizada deve gerar uma nova importação, sem alterar a cópia bruta.

Use as garantias de integridade do SQL

Chaves primárias e únicas definem identidade, chaves estrangeiras representam relações e restrições de verificação protegem invariantes independentemente de quem grava. Uma consulta de relatório não deve ser o único lugar que detecta um status impossível ou quantidade negativa. Separe tabelas de preparação das tabelas confiáveis; promova apenas o que passar pelo contrato de validação. Parametrize consultas e restrinja os dados por cliente quando houver múltiplos locatários.

Reconcilie antes de trocar o relatório

Durante um período de sobreposição, gere o relatório antigo e o novo modelo SQL a partir da mesma captura da origem. Compare quantidade de linhas, totais por dimensões úteis, registros excluídos, nulos, chaves duplicadas e limites de horário. Documente diferenças aceitas e seus motivos. Um pipeline verde não prova equivalência se o fuso, o arredondamento de moeda ou a interpretação de uma fórmula mudou.

Registre a versão do relatório, os lotes de entrada, a versão da transformação e o horário de geração. Defina se correções na origem recalculam relatórios históricos ou se eles permanecem como foram emitidos. Isso é uma política de negócio, não uma decisão automática do banco.

Migre por etapas

Comece com ingestão somente de leitura e relatórios paralelos. Depois torne o modelo SQL a referência oficial, mantendo uma exportação controlada ou planilha de revisão para quem realmente precisa dela. Só então elimine a cópia manual. Para cada etapa, defina responsável, condição de reversão, limite de divergência e data de comunicação. Evite permitir edição independente nos dois lugares por tempo indeterminado: isso cria fontes da verdade concorrentes.

Em resumo

Migre quando concorrência, repetibilidade, controle de acesso ou auditoria já não cabem bem na planilha, mas preserve as decisões humanas que são intencionais. Construa o pipeline com cópias brutas, validação explicável, restrições relacionais e reconciliação antes da virada. Amadurecer o processo não significa abolir planilhas; significa dar clareza à responsabilidade e confiança aos relatórios.