Migração de Firebird para Oracle – For Select

[fsitjaParticipante]

Digo “ultrapassada” pois deveria ter sido deprecada já, devido à performance muito ruim que apresenta.

Por exemplo, você jamais vai querer fazer um cursor for loop onde o cursor possui milhões de linhas, ou até mesmo 100 mil ou mais, fazendo updates, selects, inserts ou deletes dentro do loop. É terrível em matéria de performance.

É mais ou menos a seguinte analogia:
Você vai na biblioteca, chega no balcão e pede um livro. A pessoa vai até as prateleiras, procura o livro, pega ele e leva até você. Daí você dá uma olhada no livro, usa ele e faz o que precisa, volta no balcão e pede um outro livro. A moça vai de novo nas prateleiras, procura o livro, acha, pega e retorna para você… você vai para a mesa, trabalha com ele, etc etc…

Repita a operação suficientemente e prepare-se para ser ofendido ou estapeado.

Não seria muito mais fácil levar uma “listinha” com os livros para a pobre da moça, pedir todos de uma vez, ela voltar com os braços cheios de livros e você fazer tudo o que precisa com eles de uma vez só?

É a mesma coisa com o banco de dados. Exceto que ele não te xinga de cobras e lagartos se você abusar da boa vontade dele. 🙄

Fazer com loop envolve:
1 – sair do PL/SQL
2 – ir pro banco de dados e fazer o fetch de uma linha
3 – retornar ao PL/SQL com a linha
4 – processar a transformação ou lógica de negócio
5 – fazer o select/update/insert/delete necessário dentro do loop, que significa sair para o engine do SQL novamente
7 – retornar ao engine do PL/SQL
8 – retornar ao passo 1

Isso tudo para cada uma das milhares, milhões ou bilhões de linhas. Sai muito custoso isso tudo. O simples fato de chavear context do PL/SQL para o SQL, que pode ser imperceptível se realizado meia dúzia de vezes, multiplicado por mil ou por um milhão, vira uma eternidade para o usuário esperando a transação terminar.

E isso não vale só para PL/SQL. Vale para Java, para PHP, .NET enfim, qualquer linguagem que tenha interação com o banco de dados. Por isso a interface das procedures tem que ser cuidadosamente definida e, possivelmente, ter variações que recebam lotes (arrays, collections) para operações com bulk collect.

O PL/SQL pelo menos tem a “esperteza” de usar bind variables nos SQLs, enquanto que nas outras linguagens o desenvolvedor precisa fazer o binding manualmente. Senão a coisa toda piora muito mais e o servidor sofre fazendo parse e plano de acesso para cada comando SQL enviado.

Já o bulk collect trabalha em lotes de linhas, assim como a listinha na biblioteca.

Reduza o overhead. Maximize a utilização de recursos.

Não é só porque funciona que está correto.