Eu herdei um banco de dados que contém vários procedimentos com 1.000 a 1.500 linhas, com subseleções aninhadas complexas que chegam a 7 ou 8 níveis de profundidade em alguns lugares. Eu preciso refatorá-los desesperadamente para minha própria sanidade, mas como posso começar a fazer isso com qualquer nível de confiança de que eles ainda funcionam da mesma forma?
Eu escreveria testes de unidade se fosse .Net - você recomenda uma abordagem semelhante?
Sim, crie testes de unidade. Esta é realmente a única maneira de garantir que uma versão modificada atenda aos mesmos requisitos do original.
Para refatorar os procedimentos, procure padrões repetidos de código que possam ser extraídos em procedimentos separados ou aninhados. Se os procedimentos ainda forem muito longos, divida partes dele em procedimentos separados, cada um completando uma tarefa. Ao interromper novos procedimentos, você deve adicionar testes de unidade para eles.
Sete ou oito níveis de subseleções soam excessivos, mas você pode achar que alguns ou mesmo a maioria deles são necessários para produzir os dados necessários. Eu me concentraria no procedimento inicialmente e depois lidaria com o SQL.
Para fazer testes de unidade no Oracle, o principal produto comercial para testes é o Code Tester da Quest . A Oracle tem Unit Testing embutido em seu produto SQL Developer gratuito . A questão Teste de unidade para PL/SQL no StackOverflow tem algumas outras opções ou você pode simplesmente escrever seus próprios testes.
talvez você possa encontrar bons conselhos aqui:
Enquanto isso, tente identificar consultas de aparência desagradável, como as que usam
whereem vez dejoins.Quanto aos meus dois centavos aqui, geralmente passo por um reformatador, se posso, para levar as coisas a um nível rastreável, porque qualquer coisa com 1.500 linhas, a menos que já reformatado, será um pouco difícil de rastrear manualmente.
Em seguida, tento colocar seleções profundamente aninhadas em tabelas temporárias para reduzir o aninhamento.
Em seguida, tento descobrir se ele pode ser dividido em pedaços contíguos de código, que podem ser extraídos para serem executados por si mesmos (pense em criar funções menores a partir de um único método longo de C #) e encapsulados para evitar que muitas informações sejam apresentadas em um longo trecho.
Esses são os meus fundamentos que eu lanço no problema antes de me afastar muito do tópico