Hvad er lagrede procedurer, og hvornår bør du bruge dem?

Question

Accepted Answer

En **lagret procedure** er et sæt af SQL-sætninger (og proceduremæssig logik) gemt i databasen og udført efter navn. Den kører logik *indeni* databasen i stedet for i applikationskode. De har virkelige fordele, men også betydelige afvejninger, så hvornår man skal bruge dem er en ægte designbeslutning.

## En lagret procedure

```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 procedure samler SQL og proceduremæssig logik (variabler, betingelser, løkker, fejlhåndtering) i en navngivet, genbrugelig databaserutine. Funktioner er lignende, men returnerer en værdi.

## Potentielle fordele

```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 afvejninger (hvorfor mange undgå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)
```

## Hvornår skal du bruge 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 betyder noget

At forstå lagrede procedurer — herunder deres afvejninger — er værdifuld viden, fordi de repræsenterer en ægte arkitektonisk valg med virkelige fordele og virkelige ulemper, og at vide *hvornår* man skal bruge dem (og hvornår man ikke skal) afspejler modent skøn.

Lagrede procedurer kan tilbyde **ydeevnefordele** (at køre multi-trinlogik indeni databasen undgår netværksrundture), reduceret netværkstrafik, genbrugelse på tværs af klienter, sikkerhed (at give udførelsestilladelse uden tabeladgang) og centraliseret konsistens — hvilket gør dem passende for ydeevnekritiske dataintensive operationer, batchbehandling og logik, der skal håndhæves på databaseniveau på tværs af flere applikationer.

Men at forstå de **betydelige afvejninger** er lige så vigtig og afspejler moderne praksis: at placere forretningslogik i databasen gør det sværere at versionskontrollere, teste og vedligeholde (logik delt mellem app og database), binder dig til en bestemt databases proceduresprog (PL/pgSQL, T-SQL, PL/SQL — reducerer portabilitet), er sværere at debugge, og tilføjer belastning på databaselaget (ofte det sværeste at skalere).
\
af disse grunde **favoriserer moderne applikationsudvikling ofte at holde forretningslogik i applikationslaget** (testbar, portabel, versionskontrolleret) i stedet for i lagrede procedurer.

Hovedpointer er **skønnet for hvornår de skal bruges** — passende for specifikke ydeevnekritiske eller DB-niveau-håndhævelse-behov, men generelt undgået som standard for forretningslogik.

Da lagrede procedurer er almindelige i mange systemer (især virksomheds-/legacy-systemer), og da det at forstå både deres fordele og deres afvejninger (og den moderne tilbøjelighed til applikationslags-logik) er hvad der muliggør fornuftige arkitektoniske beslutninger, er forståelse af lagrede procedurer værdifuld viden på seniorplan, der demonstrerer evnen til at afveje database-side kontra applikations-side logik — en betydningsfuld designovervejelse og et emne, der afspejler arkitektonisk modenhed.