Procedures: Uma ferramenta poderosa, mas nem sempre bem compreendida · drumas

Há alguns anos, quando comecei a trabalhar com sistemas legados de grandes empresas — especialmente bancos, seguradoras e governos — me deparei com algo que era quase um “oráculo” para aqueles sistemas: as procedures (ou procedimentos armazenados, os famosos stored procedures).

Na época, me surpreendi ao ver que boa parte da regra de negócio estava escrita dentro do banco de dados, e não em linguagens como Java, PHP ou Python. Em vez de um serviço com regras claras e testáveis, as decisões de negócio estavam escondidas em um mar de BEGIN, IF, LOOP e RAISE EXCEPTION.

O que são stored procedures?

Em termos simples, uma procedure é um bloco de código SQL que fica armazenado dentro do próprio banco de dados. Ela pode conter instruções complexas, como condições, loops, variáveis e exceções, e pode ser chamada sempre que for necessário — como se fosse uma função no seu backend, só que rodando dentro do banco.

Por exemplo, imagine uma procedure chamada calcular_salario_mensal, que recebe um ID de funcionário e retorna o salário final, considerando descontos, horas extras e bônus. Essa lógica inteira pode ser escrita em PL/pgSQL (PostgreSQL), T-SQL (SQL Server) ou PL/SQL (Oracle), e executada com uma simples chamada SQL.

Por que tantas empresas antigas usaram (e ainda usam) procedures?

A resposta está em uma palavra: performance.

Antes da popularização de arquiteturas orientadas a serviços e APIs, era comum centralizar a lógica no banco por algumas razões:

Velocidade: o banco processava tudo internamente, evitando várias idas e voltas entre a aplicação e o servidor de dados.
Consistência: com a lógica centralizada, era mais fácil garantir que todos os sistemas usassem as mesmas regras.
Baixo custo de infraestrutura: sistemas monolíticos, rodando num servidorzão central, funcionavam melhor com essa abordagem.

Empresas como bancos, empresas de energia, telecom e órgãos públicos ainda mantêm grandes blocos de lógica dentro de procedures por serem parte vital de sistemas que "não podem parar".

As vantagens

Não dá pra negar que procedures têm seus pontos positivos, principalmente quando bem projetadas:

✅ Desempenho local: reduzem a latência por evitar chamadas repetidas à base.
✅ Reutilização: uma lógica pode ser chamada por diversos sistemas.
✅ Controle de acesso: é possível restringir o uso por roles específicas no banco.
✅ Encapsulamento da lógica: a regra fica isolada e protegida de modificações externas.
✅ Evita acoplamento com linguagens: a lógica não depende de uma linguagem do backend.

As desvantagens (e elas são muitas, quando mal utilizadas)

Apesar das vantagens, o uso indiscriminado de procedures pode causar sérios problemas:

❌ Dificuldade de versionamento: é muito mais difícil versionar, testar e fazer rollback em procedures do que em código de aplicação.
❌ Testes automatizados quase inexistentes: é raro ver cobertura de testes real em SQL procedural.
❌ Dependência de SGBD: usar PL/pgSQL ou T-SQL te prende ao PostgreSQL ou SQL Server, tornando a migração muito mais complexa.
❌ Debug complicado: encontrar bugs em procedures grandes pode ser um pesadelo — especialmente quando não há logs internos.
❌ Equipes desalinhadas: às vezes o time de backend nem sabe que a regra está no banco, criando inconsistência entre os sistemas.

E a segurança? Procedures são mais seguras?

Podem ser. Mas isso depende de como são escritas e usadas.

Uma procedure bem escrita pode ser usada para restringir o acesso direto às tabelas sensíveis. Por exemplo, um usuário pode ser autorizado a executar get_faturamento_mensal() mas não pode ver a tabela de faturamento diretamente.

No entanto, procedures mal escritas podem ser portas de entrada para:

SQL Injection (se a procedure monta comandos dinâmicos sem validação).
Vazamento de dados (sem controle de permissões adequado).
Lentidão e DoS (se loops infinitos ou consultas pesadas não forem controlados).

Como em todo software, o problema raramente está na ferramenta — mas sim em quem e como a utiliza.

Ainda vale usar procedures hoje em dia?

Depende.

Em sistemas com altíssima carga de dados, onde performance é crítica e as regras de negócio são estáveis, pode sim ser vantajoso encapsular parte da lógica no banco.

Mas no mundo moderno, onde usamos arquiteturas baseadas em microsserviços, testes automatizados, CI/CD e deploys rápidos, manter a lógica no banco pode engessar a equipe e trazer mais riscos do que benefícios.

Hoje prefiro usar procedures apenas para:

Operações complexas de ETL.
Lógicas de agregação ou cálculo muito específicos.
Cenários em que o banco já é o ponto único de verdade e segurança.

Mas nunca como o coração da regra de negócio.

Conclusão (pessoal e prática)

Procedures são como espadas afiadas. Nas mãos certas, cortam problemas com precisão e eficiência. Mas nas mãos erradas... bem, cortam o projeto inteiro.

Se você trabalha com sistemas legados, aprenda a ler e entender procedures. Se você está em um projeto novo, pense com calma se vale mesmo colocá-las no centro da sua lógica.

E, acima de tudo, documente. Porque nada é mais aterrorizante do que abrir uma procedure de 800 linhas chamada processaTudo() às 3h da manhã.

Se curtiu esse papo, comenta aí: você ainda usa procedures no seu dia a dia? Qual a maior dor que já passou por causa de uma?