Análise de Impacto de Objetos SQL

Você está realizando um rastreamento de dependência pré-mudança para um objeto de banco de dados (tabela, coluna, stored procedure, view, função ou trigger) dentro de uma base de código legada ou desconhecida. O objetivo é uma resposta única e confiável para: "Se eu mudar isso, o que mais será afetado?"

Quando usar isso

Acione quando o usuário:

• Nomeia uma tabela, coluna, stored procedure, view ou trigger específico e pergunta o que o utiliza, o que depende dele, ou se é seguro alterar/renomear/excluir
• Está prestes a modificar um elemento de esquema em uma base de código sem ORM, ou uma pilha legada mista (SQL bruto + stored procs + código de acesso a dados escrito manualmente)
• Pede um "raio de explosão", "análise de impacto" ou "rastreamento de dependência" de um objeto de banco de dados específico

Não use isso para:

• Otimização geral de desempenho SQL (use sql-optimization)
• Revisão de qualidade/segurança de código SQL (use sql-code-review)
• Análise de exposição de privacidade/PII (use data-breach-blast-radius)
• Documentação em nível de arquitetura de uma base de código inteira (use doc-and-modernize)

Processo

1. Confirme o objeto alvo e seus nomes exatos. Pergunte se for ambíguo (por exemplo, várias tabelas com nomes semelhantes, ou o usuário diz "a tabela de clientes" sem especificar o esquema). Obtenha o identificador preciso antes de pesquisar.

2. Pesquise primeiro na camada SQL:

   • Pesquise todos os arquivos .sql, definições de stored procedure, views, funções e triggers na pasta de scripts do repositório/banco de dados por referências diretas ao nome do objeto
   • Para uma coluna: verifique cada proc/view/trigger que a seleciona, insere, atualiza ou filtra
   • Para uma tabela: verifique cada proc/view/trigger que a referencia, mais relacionamentos de chave estrangeira para/de outras tabelas
   • Para uma stored procedure: verifique cada outra proc que a chama, e cada job/etapa de agente agendado que a invoca
   • Observe também referências indiretas — SQL dinâmico (EXEC(@sql)), sinônimos e views construídas sobre views

3. Pesquise na camada de aplicação:

   • Pesquise todo o código da aplicação (C#, Java, JS/TS, Angular, o que quer que o repositório contenha) por:
     • Strings SQL diretas referenciando o nome do objeto
     • Nomes de métodos ou classes de ORM/camada de acesso a dados que mapeiam para ele (por exemplo, um método de repositório chamando a stored procedure)
     • Manipuladores de endpoint de API que, em última instância, chamam o caminho de dados afetado
   • Rastreie uma camada adiante onde for razoável: um componente frontend consome um endpoint que toca este objeto? Anote, mas não persiga exaustivamente todos os consumidores de UI — sinalize "consumidores downstream adicionais provavelmente existem" se a trilha esfriar em vez de adivinhar.

4. Classifique cada achado por confiança:

   • Direto — nome do objeto encontrado literalmente no código/SQL
   • Indireto — alcançado via cadeia de chamadas de proc, mapeamento de ORM ou SQL dinâmico que não pôde ser totalmente resolvido estaticamente
   • Incertain — plausível, mas não verificado (por exemplo, construção de SQL dinâmico que não pôde ser rastreada até um nome de objeto literal)
   • Nunca apresente um achado Incertain como se fosse Direto — sinalize-o claramente para que o leitor saiba que precisa verificar manualmente

5. Produza o relatório (veja Formato de Saída abaixo).

Formato de Saída

Sempre estruture o relatório como:

1. Objeto Alvo — nome exato, tipo (tabela/coluna/proc/view/trigger) e esquema
2. Dependentes SQL Diretos — lista de procs/views/triggers/funções que o referenciam diretamente, agrupados por tipo de objeto
3. Dependentes de Código de Aplicação — lista de arquivos/classes/métodos que o referenciam, agrupados por camada (acesso a dados, API/serviço, frontend), com caminhos de arquivo
4. Referências Indiretas / Dinâmicas — qualquer coisa encontrada via SQL dinâmico, sinônimos ou cadeias de chamadas que não puderam ser totalmente resolvidas — rotuladas claramente como necessitando de verificação manual
5. Resumo de Risco — um parágrafo: este objeto é usado de forma restrita (baixo risco) ou tem um amplo alcance (alto risco)? Destaque qualquer coisa que toque um job agendado, integração externa ou camada de relatórios especificamente, pois esses geralmente são esquecidos
6. Etapas de Verificação Sugeridas — ações concretas a serem tomadas antes de fazer a mudança (por exemplo, "execute essas duas procs em dados de staging primeiro", "verifique se o endpoint do ReportingService em X depende desta coluna")

Diretrizes

• Nunca afirme que uma dependência é completa ou exaustiva — a pesquisa de texto estático não consegue capturar todas as construções de SQL dinâmico ou mapeamentos de ORM baseados em reflexão. Declare explicitamente o método de pesquisa usado e seus limites no relatório.

…