Mik azok a tárolt eljárások és mikor kell őket használni?

Question

Accepted Answer

A **tárolt eljárás** egy SQL-utasítások (és procedurális logika) halmazából álló, az adatbázisban mentett rutinprogram, amely név szerint hajtható végre. Az adatbázison *belül* futtatja a logikát az alkalmazás kódjában való futtatás helyett. Valós előnyeik vannak, de jelentős kompromisszumokkal is járnak, így a használatuk időzítése valós tervezési döntés.

## Egy tárolt eljárás

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

A tárolt eljárás SQL és procedurális logikát (változók, feltételes utasítások, ciklusok, hibakezelés) kapcsol össze egy elnevezett, újrafelhasználható adatbázis-rutinba. A függvények hasonlóak, de visszatérési értékkel rendelkeznek.

## Lehetséges előnyök

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

## A jelentős kompromisszumok (miért kerülik őket sokan ma)

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

## Mikor kell őket használni

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

## Miért számít

A tárolt eljárások megértése — beleértve azok kompromisszumait — értékes tudás, mert valódi építészeti választást reprezentálnak valós előnyökkel és hátrányokkal, és annak tudása, hogy *mikor* kell őket használni (és mikor nem), érett ítélőképesség jellemzője.

A tárolt eljárások **teljesítménybeli előnyöket** kínálhatnak (a többlépéses logika adatbázison belüli futtatása elkerüli a hálózati üzenetváltásokat), csökkentett hálózati forgalmat, újrafelhasználhatóságot az ügyfelek között, biztonságot (hajtási jogosultság biztosítása tábla-hozzáférés nélkül) és központosított konzisztenciát — így alkalmasak a teljesítménykritikus, adatintenzív műveleteknél, kötegelt feldolgozásánál és az adatbázis szintjén több alkalmazásban is érvényesítendő logika kezelésénél.

Azonban a **jelentős kompromisszumok** megértése ugyanolyan fontos és tükrözi a modern gyakorlatot: az üzleti logika adatbázisba helyezése megnehezíti a verziókezelést, tesztelést és karbantartást (logika szétaprózása az alkalmazás és az adatbázis között), egy adott adatbázis procedurális nyelvéhez köti Önt (PL/pgSQL, T-SQL, PL/SQL — csökkentve a hordozhatóságot), nehezebben debuggolható, és terhelést helyez az adatbázis rétegre (gyakran a legnehezebben skálázható).

Ezért az **modern alkalmazásfejlesztés gyakran az üzleti logika alkalmazás-rétegben történő tárolása mellett érvel** (tesztelhető, hordozható, verziókezelthető), nem pedig tárolt eljárásokba.

A kulcsfontosságú szempont a **mikor használandó ítélőképessége** — megfelelő a teljesítménykritikus vagy adatbázis-szintű érvényesítési szükségleteknél, de általában elkerülendő az üzleti logika alapértelmezéseként.

Mivel a tárolt eljárások sok rendszerben gyakoriak (különösen nagyvállalati/örökölt rendszerek), és mivel az előnyeik és kompromisszumaik (valamint az alkalmazás-réteg logikájára fordított modern orientáció) megértése olyan szilárd építészeti döntéseket tesz lehetővé, a tárolt eljárások ismerete értékes senior-szintű tudás, amely az adatbázis-oldali és alkalmazás-oldali logika közötti mérlegelés képességét demonstrálja — egy értelmes tervezési szempont és az építészeti érettséget tükröző téma.