Co jsou uložené procedury a kdy byste je měli použít?

Question

Accepted Answer

**Uložená procedura** je sada SQL příkazů (a procedurálních logiky) uložená v databázi a vykonávaná podle názvu. Spouští logiku *uvnitř* databáze místo v kódu aplikace. Mají opravdu reálné výhody, ale i významné kompromisy, takže kdy je použít je opravdu rozhodnutí o návrhu.

## Uložená 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
```

Uložená procedura sdružuje SQL a procedurální logiku (proměnné, podmínky, smyčky, zpracování chyb) do pojmenované, znovupoužitelné databázové rutiny. Funkce jsou podobné, ale vrací hodnotu.

## Potenciální výhody

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

## Významné kompromisy (proč se jim dnes mnozí vyhýbají)

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

## Kdy je používat

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

## Proč na tom záleží

Pochopení uložených procedur — včetně jejich kompromisů — je cenné znalosti, protože představují opravdické architektonické rozhodnutí s reálnými výhodami a reálnými nevýhodami, a vědět *kdy* je použít (a kdy ne) odráží zralý úsudek.

Uložené procedury mohou nabídnout **výhody výkonu** (spouštění vícekrokové logiky uvnitř databáze se vyhne síťovým cestám tam a zpět), snížený síťový provoz, znovupoužitelnost napříč klienty, bezpečnost (udělení oprávnění ke spuštění bez přístupu k tabulkám) a centralizovanou konzistenci — což je vhodné pro operace kritické na výkon s vysokým nárokem na data, dávkové zpracování a logiku, která musí být vynucena na úrovni databáze napříč více aplikacemi.

Na druhou stranu pochopení **významných kompromisů** je stejně důležité a odráží moderní praxi: vložení obchodní logiky do databáze usnadňuje verzování, testování a údržbu (rozdělení logiky mezi aplikaci a databází), váže vás na procedurální jazyk konkrétní databáze (PL/pgSQL, T-SQL, PL/SQL — snižuje přenositelnost), je těžší debugování a přidává zátěž na databázovou vrstvu (často nejtěžší na škálování).

Z těchto důvodů **moderní vývoj aplikací často upřednostňuje udržování obchodní logiky v aplikační vrstvě** (testovatelné, přenositelné, verzované) místo v uložených procedurách.

Klíčová myšlenka je **úsudek o tom, kdy je použít** — vhodné pro specifické potřeby kritické na výkon nebo vynucování na úrovni databáze, ale obecně se vyhýbají jako výchozí volba pro obchodní logiku.

Protože jsou uložené procedury běžné v mnoha systémech (zvláště enterprise/legacy) a protože pochopení jak jejich výhod tak jejich kompromisů (a moderní orientace na logiku aplikační vrstvy) je to, co umožňuje zdravá architektonická rozhodnutí, pochopení uložených procedur je cenná znalost na úrovni seniorů, která demonstruje schopnost vážit logiku na straně databáze vs na straně aplikace — důležité architektonické hledisko a téma odrážející architektonickou zralost.