Dicas para programação em PL/SQL

Olá pessoal,

   No artigo de hoje darei algumas dicas que são muito importantes para quem deseja escrever código PL/SQL com qualidade e de fácil reutilização. Algumas dessas dicas se aplicam em qualquer linguagem de programação (Itens 1, 2, 3 e 7) e são bem simples e fáceis de aplicar, portanto, qualquer iniciante conseguirá utilizá-las. Outras (Itens 4, 5 e 6), para melhor entendimento, exigem experiência ou conhecimentos de nível intermediário/avançado.

DICAS PARA PROGRAMAR COM QUALIDADE EM PL/SQL

     1- Crie blocos pequenos:

     Escreva funções ou stored procedures com no máximo 50 linhas por bloco. O número 50 é uma referência que peguei de um artigo do Mestre Steven Feuerstein (ver referências). Na minha opinião, o importante não é seguir este número à risca, mas sim, entender que escrever blocos pequenos facilita o entendimento do código e manutenções futuras. Um Desenvolvedor experiente e/ou que já trabalhou com POO (Programação Orientada a Objetos), sabe muito bem do que estou falando aqui! 

     Se o código de um objeto é muito grande, é bem provável que você consiga dividi-lo em partes menores, gastando um pouco mais de tempo revisando-o! Crie blocos de código menores, especializados, isso permite que eles sejam mais fáceis de serem reutilizados posteriormente, evita código redundante e facilita manutenções futuras!

    Exemplo:

      Ao invés de criar 1 única stored procedure para efetuar uma transferência bancária que é composta de 3 passos: verificar saldo da conta origem, retirar valor da conta origem e depositar valor na conta destino; crie 3 stored procedures especializadas para realizar cada um destes passos e chame-as a partir de uma principal, que será responsável pelo controle transacional. 

      2- Padronize seu código:

     Faça bom uso da identação, crie nomes de objetos padronizados e utilize comentários para descrever as rotinas do seu código (ver Imagem 01). Essa boas práticas irão ajudar outros programadores a entender mais facilmente o código que você escreveu, e a você mesmo, relembrar o que fez. Um código padronizado poderá evitar erros e facilitar manutenções futuras. Você gastará um pouco mais de tempo para criar o seu código, mas tenha ciência de que no futuro você poderá economizar muito tempo com a manutenção dele!

Imagem 01 - Exemplos de código sem padronização X código padronizado

     3- Utilize controle de versão de código:

     Utilize em PL/SQL as mesmas técnicas de controle de versão de código que você utilizaria em qualquer outra linguagem de programação (Ex.: Dot net, Java, VB6, Delphi etc.), pois existe um grande risco de você ter que voltar a versão anterior do código de um objeto (já tive que fazer isso várias vezes como Desenvolvedor e também como DBA). Para melhor entender esta dica, sugiro a leitura do artigo Repositório de metadados/Versionamento de objetos no Oracle Database.

     4- Evite transações autônomas:

     Sempre que for possível, evite transações autônomas. Elas são muito úteis para resolver alguns problemas no gerenciamento de transações, mas se forem mal utilizadas, podem gerar resultados inesperados, e até mesmo, erros em suas aplicações.

     5- Utilize Packages:

     Crie funções e stored procedures dentro de packages. Os packages oferecem inúmeros benefícios: permitem organizar melhor os blocos de código relacionados, encapsular o código dos seus objetos, criar objetos locais, efetuar sobrecarga de objetos, quebrar a cadeia de dependência entre objetos etc.

     6- Evite triggers:

     Triggers são muito úteis, mas o seu uso também pode gerar resultados inesperados. É importante ter ciência de que o código do trigger está contido na mesma transação da instrução SQL que o disparou, portanto, se o SQL do trigger falhar, o SQL que o disparou também irá falhar, e na maior parte das vezes não é isso o que precisamos (já vi isso acontecer algumas vezes). Existem ainda outros problemas relacionados ao uso dos triggers, que podem muitas vezes serem evitados se você invocar explicitamente uma stored procedure dentro da sua aplicação! Para isso faça um bom planejamento dela. Vejo muitos triggers serem criados para remendar funcionalidades da aplicação e depois gerarem problemas maiores do que aqueles para o qual eles foram criados para resolver!

     Se não for possível evitar os triggers, evite pelo menos escrever o código dentro deles. Crie um stored procedure, coloque o código lá dentro e chame-o dentro do trigger. Isso possibilita a reutilização de código e é a única solução para a criação de triggers com transações autônomas até o Oracle 10G.

     7- Libere rapidamente objetos não utilizados

     Utilize um objeto o mais tarde possível e libere-o o mais cedo possível. Ao terminar de usar um cursor que foi declarado explicitamente, FECHE-O imediatamente! Se você vai utilizar uma collection somente no final de um bloco PL/SQL, popule-a o mais tarde possível, e não no início do bloco. Esta dica, de um modo geral, nos ajuda a economizar memória e pode até evitar bloqueios desnecessários, podendo deste modo, otimizar a performance do bloco PL/SQL e de todo o Banco de Dados.

  

     Bom pessoal, por hoje é só! As dicas apresentadas acima fazem parte de um capítulo do treinamento em videoaulas PL/SQL Essentials and Tuning. Se você quiser aprender mais e se tornar um Expert em PL/SQL, participe deste treinamento!

[]s

  

Referências:

     - Cleaning Up PL/SQL Practices, Steven Feuerstein, Oracle Maganize 
     - 40 tips from Tom