O que são procedimentos armazenados e quando você deve usá-los?

Question

Accepted Answer

Um **procedimento armazenado** é um conjunto de instruções SQL (e lógica procedural) salvo no banco de dados e executado pelo nome. Ele executa a lógica *dentro* do banco de dados em vez de no código da aplicação. Eles têm benefícios reais, mas também compensações significativas, portanto quando usá-los é uma decisão genuína de design.

## Um procedimento armazenado

```sql
-- define a procedure that encapsulates logic in the database
CREATE PROCEDURE transfer_funds(from_id INT, to_id INT, amount DECIMAL)
LANGUAGE plpgsql AS $$
BEGIN
  UPDATE accounts SET balance = balance - amount WHERE id = from_id;
  UPDATE accounts SET balance = balance + amount WHERE id = to_id;
  -- can include logic: conditionals, loops, error handling, transactions
END;
$$;

CALL transfer_funds(1, 2, 100);   -- execute by name
```

Um procedimento armazenado agrupa SQL e lógica procedural (variáveis, condicionais, loops, tratamento de erros) em uma rotina de banco de dados nomeada e reutilizável. Funções são semelhantes, mas retornam um valor.

## Benefícios potenciais

```text
✓ Performance — runs IN the database (no round-trips for multi-step logic); precompiled
✓ Reduced network traffic — one call vs many queries from the app
✓ Reusability — shared logic callable from multiple applications/clients
✓ Security — grant EXECUTE on a procedure without granting table access; reduces
  injection surface (parameterized)
✓ Consistency — centralize critical logic so all clients use the same implementation
```

## As compensações significativas (por que muitos os evitam hoje)

```text
✗ Business logic in the DATABASE → harder to version-control, test, and maintain
  (logic split between app code and the database)
✗ Database-specific (PL/pgSQL vs T-SQL vs PL/SQL) → less portable, vendor lock-in
✗ Harder to debug than application code; weaker tooling
✗ Scaling — the database is often the hardest tier to scale; pushing logic there
  can increase its load
✗ Modern apps often prefer logic in the application layer (testable, portable, versioned)
```

## Quando usá-los

```text
✓ Performance-critical data-intensive operations (heavy multi-step DB logic, batch jobs)
✓ Logic that MUST be enforced at the DB level across multiple clients
✓ Reducing round-trips for operations involving many queries
✗ AVOID putting general business logic in procedures by default — modern practice
  usually favors the application layer (better testing, versioning, portability)
```

## Por que isso importa

Compreender procedimentos armazenados — incluindo suas compensações — é um conhecimento valioso porque representam uma escolha arquitetônica genuína com benefícios reais e desvantagens reais, e saber *quando* usá-los (e quando não usar) reflete um julgamento maduro.

Procedimentos armazenados podem oferecer **benefícios de desempenho** (executar lógica de múltiplas etapas dentro do banco de dados evita round-trips de rede), redução de tráfego de rede, reutilização entre clientes, segurança (conceder execute sem acesso à tabela) e consistência centralizada — tornando-os apropriados para operações críticas de desempenho intensivas em dados, processamento em lote e lógica que deve ser aplicada no nível do banco de dados em múltiplas aplicações.

Porém, compreender as **compensações significativas** é igualmente importante e reflete a prática moderna: colocar lógica de negócios no banco de dados torna mais difícil controlar versão, testar e manter (dividindo lógica entre aplicação e banco de dados), vincula você à linguagem procedural de um banco de dados específico (PL/pgSQL, T-SQL, PL/SQL — reduzindo portabilidade), é mais difícil depurar e adiciona carga ao tier do banco de dados (frequentemente o mais difícil de escalar).

Por essas razões, **o desenvolvimento moderno de aplicações frequentemente favorece manter a lógica de negócios na camada de aplicação** (testável, portável, controlada por versão) em vez de em procedimentos armazenados.

O insight principal é o **julgamento de quando usá-los** — apropriado para necessidades específicas críticas de desempenho ou aplicação no nível do DB, mas geralmente evitado como padrão para lógica de negócios.

Como procedimentos armazenados são comuns em muitos sistemas (especialmente enterprise/legado), e como compreender tanto seus benefícios quanto suas compensações (e a inclinação moderna para lógica na camada de aplicação) é o que permite decisões arquitetônicas sólidas, compreender procedimentos armazenados é um conhecimento valioso de nível sênior que demonstra a capacidade de avaliar lógica no lado do banco de dados versus lado da aplicação — uma consideração de design significativa e um tópico que reflete maturidade arquitetônica.