Što su spremljene procedure i kada bi ih trebali koristiti?

Question

Accepted Answer

**Spremljena procedura** je skup SQL naredbi (i proceduralne logike) spreman u bazi podataka i izvršava se po imenu. Izvršava logiku *unutar* baze podataka umjesto u kodu aplikacije. Imaju stvarne prednosti, ali i značajne kompromise, pa je odluka o tome kada ih koristiti pravi dizajnerski izbor.

## Spremljena procedura

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

Spremljena procedura kombinira SQL i proceduralnu logiku (varijable, uvjetne naredbe, petlje, rukovanje greškama) u imenovanu, ponovnu bazu podataka rutinu. Funkcije su slične, ali vraćaju vrijednost.

## Mogući benefiti

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

## Značajni kompromisi (zašto ih mnogi izbjegavaju danas)

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

## Kada ih koristiti

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

## Zašto je to važno

Razumijevanje spremljenih procedura — uključujući njihove kompromise — je dragocjeno znanje jer predstavljaju pravi arhitekturni izbor s stvarnim prednostima i stvarnim nedostacima, a znanje *kada* ih koristiti (i kada ne) odražava zrelu prosudbu.

Spremljene procedure mogu ponuditi **prednosti performansi** (izvršavanje multi-step logike unutar baze podataka izbjegava mrežne okretaje), smanjenje mrežnog prometa, ponovno korištenje na svim klijentima, sigurnost (dodjela dozvole izvršavanja bez pristupa tablici), i centralizirane konzistentnosti — čineći ih prikladnim za kritične operacije koje zahtijevaju performanse s puno podataka, obradu u grupama, i logiku koja mora biti provedena na razini baze podataka na više aplikacija.

Međutim, razumijevanje **značajnih kompromisa** je jednako važno i odražava modernu praksu: postavljanje poslovne logike u bazu podataka čini je težom za kontrolu verzija, testiranje, i održavanje (dijeljenje logike između aplikacije i baze podataka), veže vas na proceduralnu logiku specifične baze podataka (PL/pgSQL, T-SQL, PL/SQL — smanjuje prenosivost), teže je ispravljati greške, i dodaje opterećenje razini baze podataka (često najtežem za skaliranje).

Iz tih razloga, **moderne aplikacije često favre zadržavanje poslovne logike u sloju aplikacije** (testabilno, prenosivo, s kontrolom verzija) umjesto u spremljenim procedurama.

Ključna spoznaja je **prosudba kada ih koristiti** — prikladne za specifične potrebe kritične za performanse ili provođenje na razini baze podataka, ali općenito izbjegavane kao zadana opcija za poslovnu logiku.

Budući da su spremljene procedure česte u mnogim sustavima (posebno u poslovnom/naslijeđenom okruženju), i budući da razumijevanje i njihovih prednosti i njihovih kompromisa (i moderne tendencije prema logici u sloju aplikacije) omogućuje zvučne arhitekturne odluke, razumijevanje spremljenih procedura je dragocjeno znanje na razini seniora koje pokazuje sposobnost vaganja logike na strani baze podataka nasuprot logike na strani aplikacije — značajno razmatranje dizajna i tema koja odražava arhitekturnu zrelost.