Kaj so shranjene procedure in kdaj jih uporabiti?

Question

Accepted Answer

**Shranjena procedura** je niz SQL-stavkov (in proceduralne logike) shranjen v bazi podatkov in izvršen po imenu. Izvršuje logiko *znotraj* baze podatkov, ne pa v kodi aplikacije. Imajo prave koristi, vendar tudi pomembne kompromise, zato je odločitev, kdaj jih uporabiti, pravo oblikovalsko vprašanje.

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

Shranjena procedura povezuje SQL in proceduralno logiko (spremenljivke, pogojne stavke, zanke, obdelava napak) v poimenovan, ponovno uporaben rutinski program baze podatkov. Funkcije so podobne, vendar vrnejo vrednost.

## Potencialne koristi

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

## Pomembni kompromisi (zakaj jih mnogi danes izogibajo)

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

## Kdaj jih uporabiti

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

## Zakaj je to pomembno

Razumevanje shranjenih procedur — vključno z njihovimi kompromisi — je dragoceno znanje, ker predstavljajo pravo arhitekturno odločitev s pravimi koristmi in pravimi slabostmi, in znanje *kdaj* jih uporabiti (in kdaj jih ne) odraža zrelo sodbo.

Shranjene procedure lahko ponujajo **koristi glede zmogljivosti** (zagon večstopenjske logike znotraj baze podatkov se izogne omrežnim povratnim tokom), zmanjšan promet v omrežju, ponovno uporabnost med odjemalci, varnost (dodelitev izvršitve brez dostopa do tabel) in osredinjeno skladnost — zato so primerne za operacije, kritične za zmogljivost in intenzivne s podatki, obdelavo paketov in logiko, ki mora biti izvršena na ravni baze podatkov v več aplikacijah.

Hkrati je razumevanje **pomembnih kompromisov** enako pomembno in odraža sodobno prakso: umestitev poslovne logike v bazo podatkov otežka verzioniranje, testiranje in vzdrževanje (razdelitev logike med aplikacijo in bazo podatkov), vas veže na proceduralni jezik določene baze podatkov (PL/pgSQL, T-SQL, PL/SQL — zmanjšuje prenosljivost), je težje za razhroščevanje in povečuje obremenitev nivoja baze podatkov (pogosto najtežje za skaliranje).

Za te razloge **sodobna razvoj aplikacij pogosto favorizira ohranitev poslovne logike v plasti aplikacije** (preskušljivo, prenosljivo, nadzoruje se verzija) namesto v shranjenih procedurah.

Ključni vpogled je **sodba o tem, kdaj jih uporabiti** — primerno za specifične potrebe glede zmogljivosti ali uveljavljanja na ravni baze podatkov, vendar se jih na splošno izogibajo kot privzeto za poslovno logiko.

Ker so shranjene procedure pogoste v številnih sistemih (še posebej podjetniški/zastareli), in ker razumevanje tako njihovih koristi kot njihovih kompromisov (in sodobna nagnjenja k logiki na plasti aplikacije) omogoča zdrave arhitekturne odločitve, je razumevanje shranjenih procedur dragoceno znanje na ravni starejšega strokovnjaka, ki kaže sposobnost tehtanja logike na strani baze podatkov v primerjavi s stranjo aplikacije — važno oblikovalsko vprašanje in tema, ki odraža arhitekturno zrelost.