Seu banco de dados sabe mais sobre sua empresa do que a documentação

TL;DR

• Depois de décadas de ERP, o banco de dados vira a arqueologia da empresa: cada tabela, coluna e stored procedure guarda uma decisão que a documentação esqueceu.
• Campo “inútil” e procedure estranha quase sempre têm história — antes de apagar, descubra por que alguém precisou criá-lo.
• Dependências invisíveis (planilhas, scripts de cliente, jobs esquecidos) fazem estruturas antigas morrerem de forma silenciosa e cara.
• IA amplifica o risco: ela interpreta o schema pelo que parece, não pelo que a empresa fez com ele.
• Pragmatismo: registre o “porquê” na hora que se descobre, classifique em três baldes, e só mate o que está morto com prova.
• Antes de apagar aquela coluna inútil criada em 2007, descubra por que alguém achou necessário criá-la.

~ 9 min de leitura · 1618 palavras

O banco como memória histórica da empresa

Documentação mente. Não por malícia — por abandono. O diagrama ficou no wiki que ninguém atualiza desde 2016, o analista que documentou saiu em 2019, e o estagiário que preencheu o comentário da tabela foi promovido para outra área. O banco, não. O banco está lá, funcionando, todas as segundas-feiras, há vinte anos.

Eu mantenho um ERP há décadas e aprendi a ler o schema como quem lê uma escavação: cada camada é uma época da empresa. A tabela de vendas tem campos que refletem quando o negócio era varejo, colunas que nasceram quando entrou o atacado, e uma seção inteira que só faz sentido para o período em que o cliente participava de uma regulação que ninguém lá lembra mais.

Quando alguém me pergunta “como funciona a regra de crédito?”, minha primeira resposta é: “deixa eu ver como a regra foi gravada, não como ela foi escrita”. O schema não tem intenção — ele tem consequência. E consequência gravada em disco não mente.

Tabelas antigas carregam conhecimento que ninguém mais tem

Uma tabela criada em 2004 pode ser a única evidência viva de uma regra comercial que morreu da memória de todos. Um exemplo típico de ERP: uma tabela de cadastros fiscais com um campo de “série” que ninguém usa mais, mas que controlava diferencial de alíquota para operações interestaduais antes de uma mudança de convênio. Ninguém lembra. O schema lembra.

Isso muda completamente a conversa de modernização. A pergunta não é “essa tabela é necessária hoje?” — é “que pergunta do negócio essa tabela respondia quando foi criada?”. Se você não sabe responder a segunda, você não tem autoridade para responder a primeira com um DROP.

Stored procedures esquecidas são o mesmo problema em versão pior. Procedure sem comentário, com cursor e tabela temporária, que ninguém toca há dez anos. Aí alguém “limpa” ela — e descobre três meses depois que uma exceção fiscal de determinado estado passou a ser calculada errado. A procedure estava morta para o time de TI e viva para o fisco.

O campo aparentemente inútil

Todo banco de ERP maduro tem aquele campo que parece ruído: `FLAG_A`, `CAMPO_OBS2`, `VL_DESC_PCT_OLD`. Instinto natural: apagar.

O instinto erra com frequência desconfortável. Na prática de décadas vendo isso, os motivos mais comuns para o campo aparentemente inútil existir:

• Exigência de cliente importante — aquela informação alimentava um relatório ou integração específica de quem pagava uma boa fatia da mensalidade.
• Exceção fiscal — campo criado para um caso de tributação que voltava sazonalmente.
• Performance histórica — coluna desnormalizada que evitava um JOIN pesado em tabelas de milhões de linhas, em época de hardware muito pior.
• Migração truncada — uma conversão de schema que foi interrompida e nunca retomada.

Três dessas quatro razões são regras de negócio disfarçadas de lixo técnico. A quarta é lixo técnico de verdade. Você não distingue uma da outra lendo o nome da coluna — a distinção vem de perguntar e rastrear uso.

Dependências invisíveis: o que morre junto

O maior risco ao limpar estruturas antigas não é apagar a tabela errada. É apagar a tabela certa e não saber quem tinha dependência nela.

Dependência visível é a que o SSMS mostra: foreign key, view, procedure no mesmo banco. Depois vêm as menos visíveis: código aplicativo com SQL string embutido, job do SQL Agent, DTS/SSIS que ninguém abre há anos, importação de retaguarda, integração com o webservice de um parceiro.

E depois vem a camada que o banco não mostra de jeito nenhum: a planilha do financeiro que conecta via Excel na view que ninguém sabe que existe, o relatório do contador exportado por macro, o script que o próprio cliente escreveu em VB6 em 2009 e roda na máquina do caixa. Essa camada morde sem aviso.

A regra prática que uso: antes de remover qualquer estrutura, faça a mesma pergunta em três tempos — quem usa hoje, quem usou nos últimos 12 meses, e quem pode estar usando sem eu saber. A terceira pergunta vale mais que a primeira, e é a única que exige trabalho de verdade.

Por que IA interpreta errado estruturas antigas

Aqui está o risco novo. Todo mundo quer apontar IA no schema antigo para “entender o legado”. Eu também quero — e uso. Mas a IA tem um viés perigoso nesse contexto específico: ela raciocina pelo que o schema parece dizer, não pelo que a empresa fez com ele.

Um modelo olha `CAMPO_OBS2` e conclui: “nome genérico, sem FK, sem índice, provavelmente abandonado”. A análise é tecnicamente correta e errada em negócio. O campo pode ser lido por uma rotina que a IA nunca viu, carregado por um import que roda uma vez por ano, ou consumido por um relatório fora do banco.

IA amplifica o risco de outra forma também: ela é confiante e fluente. Quando você pede “documente essa coluna”, ela documenta com convicção — e a convicção é fabricada sobre o mesmo schema que já enganou três analistas juniores. Em banco de ERP com décadas de exceção fiscal, a diferença entre o que parece e o que é é literalmente dinheiro.

O uso correto de IA aqui é como gerador de hipóteses, não como fonte de verdade: “quais tabelas parecem não ter uso?”, “onde essa coluna tem uso potencial?”, “quais procedures tocam essa tabela?”. A validação final continua sendo humana, com acesso ao histórico e ao negócio.

Data lineage: de onde vem, para onde vai

Aí entra data lineage: entender de onde cada dado veio e para onde vai. Em banco grande você não consegue isso na cabeça — precisa de método.

• Origem: quem grava nessa coluna? (INSERT/UPDATE no código, import, procedure)
• Transformação: ela alimenta views, procedures, cálculos?
• Destino: quem lê? (aplicação, relatório, exportação, integração)
• Impacto: se esse dado não existisse, o que quebraria?

O ponto pragmático: para decidir o que pode morrer, você não precisa de lineage completo do banco — precisa dele nas estruturas candidatas a remoção. Tentar mapear o banco inteiro é projeto de seis meses que ninguém termina. Mapear as 30 estruturas suspeitas é uma semana e meia.

E tem um atalho valioso que quase ninguém usa: as DMVs do próprio SQL Server. `sys.dm_exec_query_stats` com `sys.dm_exec_sql_text` mostram quais estruturas realmente aparecem na carga de trabalho recente. `sys.dm_sql_referenced_entities` revela referências dentro do banco. Não é prova — é um bom filtro para a lista de suspeitos.

Como documentar um banco com centenas de tabelas

A resposta profissional a essa pergunta é decepcionante: você não documenta tudo — você documenta sob demanda e registra o que descobriu.

Documentação de banco de ERP tem um problema clássico: ninguém vai ler 400 páginas de dicionário de dados, e qualquer documento desse tamanho está desatualizado no dia em que é impresso. O que funciona:

• Comentário vivo no próprio banco — `sp_addextendedproperty` no SQL Server: documentação junto do objeto, visível no dia em que alguém for mexer nele.
• Registro de decisão, não de esquema — quando alguém descobre por que uma coluna existe, essa descoberta vira entrada num log de “porquês”, com data e contexto. É isso que se perde quando o analista sai.
• Padrão de nomenclatura escrito — meia página vale mais que 400 do dicionário: o que significa o prefixo, o que significa o sufixo, qual a diferença entre duas tabelas parecidas.
• Proibição do campo anônimo — nada de `FLAG_1` a partir de hoje. Se não tem nome que conta história, não entra.

O critério de prioridade é custo de erro: documente com carinho as estruturas que tocam dinheiro e obrigação fiscal. Uma coluna de observação interna pode viver sem documentação; um cálculo de ICMS não.

Como decidir o que pode morrer na modernização

Aqui está o coração da decisão prática da migração. Meu método classifica as estruturas em três baldes, com regra diferente para cada:

• Balde 1 — Vivo e usado: migra para a arquitetura nova, com atenção especial às regras de negócio acumuladas. Não é só copiar estrutura — é documentar o porquê de cada exceção que a estrutura carrega.
• Balde 2 — Dormente, origem desconhecida: não migre e não apague. Congele. Mantenha em um database de arquivo com o histórico, e estabeleça prazo de observação — sugiro um ciclo fiscal completo, 12 meses, porque há regras que só aparecem no fechamento. Se ninguém chorar, o balde vira o 3.
• Balde 3 — Confirmadamente morto: apague. Mas com audiência de arqueologia antes: quem criou, por quê, quando parou de ser usado. Essa última passagem documenta a decisão para o próximo ciclo de dez anos.

O erro clássico da modernização é tratar o balde 2 como o 3 e apagar tudo que parece dormente. O erro inverso é tratar o 3 como 2 e carregar décadas de estruturas mortas para dentro do sistema novo — aí a “migração” vira um transplante de arqueologia inteira na arquitetura nova, e você recria o mesmo problema com tecnologia moderna.

O mecanismo que fecha o processo: toda estrutura recebe marca de data e decisão — status, motivo, data da decisão. Sem isso, daqui a dez anos alguém vai estar exatamente na mesma conversa, com menos contexto do que você tem hoje.

A documentação que você já tinha era o banco

No fim, a tese é quase provocativa: a melhor documentação do seu sistema não está no wiki, no Confluence ou no Word do analista que saiu. Está no schema, nos dados e no comportamento do banco — mas escrita em linguagem que ninguém leu ainda.

A modernização não é projetar a estrutura nova no vácuo e pedir perdão depois. É escutar o que o banco tem a dizer antes de decidir quem sobrevive à migração.

E o banco vai falar. Só falta alguém disposto a ouvir.

Leitura relacionada

• O bug mais caro não é o que derruba o sistema — dados errados acumulados por semanas, sem ninguém perceber.
• IA na modernização de sistemas legados — onde IA gera hipótese e humano valida antes de apagar.