Ce sunt procedurile stocate și când ar trebui să le utilizezi?

Question

Accepted Answer

O **procedură stocată** este un set de instruciuni SQL (și logică procedurală) salvate în baza de date și executate după nume. Rulează logica *în interiorul* bazei de date mai degrabă decât în codul aplicației. Au beneficii reale, dar și compromisuri semnificative, deci când să le folosești este o decizie genuină de design.

## O procedură stocată

```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
```

O procedură stocată grupează SQL și logică procedurală (variabile, condiționări, bucle, gestionarea erorilor) într-o rutină de bază de date numită și reutilizabilă. Funcțiile sunt similare, dar returnează o valoare.

## Beneficii potențiale

```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
```

## Compromisurile semnificative (de ce mulți le evită astazi)

```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)
```

## Când să le utilizezi

```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)
```

## De ce conteaza

Înțelegerea procedurilor stocate — inclusiv compromisurile acestora — este cunoaștere valoroasă deoarece reprezintă o alegere arhitecturală genuină cu beneficii și dezavantaje reale, iar știind *când* să le utilizezi (și când nu) reflectă o judecată matură.

Procedurile stocate pot oferi **beneficii de performanță** (rularea logicii multi-pas în interiorul bazei de date evită apelurile de rețea multiple), trafic de rețea redus, reutilizabilitate între clienți, securitate (acordarea de drepturi de execuție fără acces la tabel) și consistență centralizată — ceea ce le face potrivite pentru operații critice de performanță cu volum mare de date, procesare în lot și logică care trebuie aplicată la nivel de bază de date în mai multe aplicații.

Totuși, înțelegerea **compromisurilor semnificative** este la fel de importantă și reflectă practica modernă: plasarea logicii comerciale în baza de date o face mai greu de controlat versiunea, testat și întreținut (împărțind logica între aplicație și bază de date), te leagă de limbajul procedural specific bazei de date (PL/pgSQL, T-SQL, PL/SQL — reducând portabilitatea), este mai greu de depanare și adaugă sarcină la nivelul bazei de date (adesea cel mai greu de scalat).

Pentru aceste motive, **dezvoltarea modernă a aplicațiilor adesea favorizează păstrarea logicii comerciale în stratul aplicației** (testabil, portabil, controlat versiunea) mai degrabă decât în proceduri stocate.

Punctul cheie este **judecata de când să le utilizezi** — potrivite pentru nevoile specifice critice de performanță sau de aplicare la nivel de bază de date, dar în general evitate ca implicit pentru logica comercială.

Deoarece procedurile stocate sunt comune în multe sisteme (mai ales enterprise/moștenite), și deoarece înțelegerea atât a beneficiilor lor cât și a compromisurilor (și tendința modernă către logica la nivel de aplicație) este ceea ce permite decizii arhitecturale corecte, înțelegerea procedurilor stocate este cunoaștere de nivel senior valoroasă care demonstrează capacitatea de a cântări logica la nivel de bază de date vs logica la nivel de aplicație — o considerație semnificativă de design și un subiect reflectând maturitate arhitecturală.