Hva er lagrede prosedyrer og når bør du bruke dem?

Question

Accepted Answer

En **lagret prosedyre** er et sett med SQL-setninger (og prosessuell logikk) som er lagret i databasen og kjørt etter navn. Den kjører logikk *inne* i databasen i stedet for i programkoden. De har virkelige fordeler, men også betydelige avveiinger, så når de skal brukes er et genuint designvalg.

## En lagret prosedyre

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

En lagret prosedyre samler SQL og prosessuell logikk (variabler, betingelses-utsagn, løkker, feilhåndtering) i en navngitt, gjenbrukbar databaserutine. Funksjoner er lignende, men returnerer en verdi.

## Potensielle fordeler

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

## De betydelige avveiningene (hvorfor mange unngår dem i dag)

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

## Når du skal bruke dem

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

## Hvorfor det er viktig

Å forstå lagrede prosedyrer — inkludert deres avveiinger — er verdifull kunnskap fordi de representerer et genuint arkitekturvalg med virkelige fordeler og virkelige ulemper, og å vite *når* de skal brukes (og når de ikke skal brukes) reflekterer modenhet i dømmekraft.

Lagrede prosedyrer kan tilby **ytelsefordeler** (kjøring av flertrinnlogikk inne i databasen unngår nettverksrundturer), redusert nettverkstrafikk, gjenbrukbarhet på tvers av klienter, sikkerhet (tildeling av execute uten tabellaksess), og sentralisert konsistens — noe som gjør dem passende for ytelses-kritiske dataintensive operasjoner, batchbehandling, og logikk som må håndheves på databasenivå på tvers av flere applikasjoner.

Men å forstå de **betydelige avveiningene** er like viktig og reflekterer moderne praksis: å plassere forretningslogikk i databasen gjør det vanskeligere å versjonkontrollere, teste og vedlikeholde (deling av logikk mellom app og database), binder deg til en spesifikk databases prosessuelt språk (PL/pgSQL, T-SQL, PL/SQL — reduserer portabilitet), er vanskeligere å feilsøke, og legger belastning på databaselaget (ofte det vanskeligste å skalere).
\
Av disse årsakene **favoriserer moderne applikasjonsutvikling ofte å holde forretningslogikk i applikasjonslaget** (testbar, portabel, versjonkontrollert) i stedet for i lagrede prosedyrer.

Hovedtanken er **dømmekraften om når de skal brukes** — passende for spesifikke ytelses-kritiske eller DB-nivå-håndhevelses-behov, men generelt unngått som standard for forretningslogikk.

Ettersom lagrede prosedyrer er vanlige i mange systemer (spesielt enterprise/legacy), og siden forståelse av både deres fordeler og deres avveiinger (og den moderne tilbøyeligheten mot applikasjonslag-logikk) er det som muliggjør gode arkitekturiske beslutninger, er forståelse av lagrede prosedyrer verdifull senior-nivå-kunnskap som demonstrerer evnen til å veie databaseside versus applikasjonside-logikk — en meningsfull designvurdering og et tema som reflekterer arkitekturmodernitet.