Vad är lagrade procedurer och när bör du använda dem?

Question

Accepted Answer

En **lagrad procedur** är en uppsättning SQL-satser (och procedurell logik) sparade i databasen och körd efter namn. Den kör logik *inuti* databasen snarare än i applikationskod. De har verkliga fördelar men också betydande avvägningar, så när man ska använda dem är ett genuint designbeslut.

## En lagrad procedur

```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 lagrad procedur samlar SQL och procedurell logik (variabler, villkorssatser, loopar, felhantering) i en namngiven, återanvändbar databasrutin. Funktioner är liknande men returnerar ett värde.

## Potentiella fördelar

```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 betydande avvägningarna (varför många undviker dem idag)

```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 bör använda 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)
```

## Varför det är viktigt

Att förstå lagrade procedurer — inklusive deras avvägningar — är värdefull kunskap eftersom de representerar ett genuint arkitekturval med verkliga fördelar och verkliga nackdelar, och att veta *när* man ska använda dem (och när man inte ska) reflekterar mogna bedömningar.

Lagrade procedurer kan erbjuda **prestandafördelar** (att köra flerstegig logik inuti databasen undviker nätverksomgångar), minskad nätverkstrafik, återanvändbarhet mellan klienter, säkerhet (att ge körpermission utan tabellåtkomst), och centraliserad konsekvens — vilket gör dem lämpliga för prestandakritiska dataintensiva operationer, batchbearbetning och logik som måste tillämpas på databasnivå över flera applikationer.

Emellertid är förståelsen av de **betydande avvägningarna** lika viktig och reflekterar modern praxis: att placera affärslogik i databasen gör det svårare att versionskontrollera, testa och underhålla (splittra logik mellan app och databas), binder dig till en specifik databass procedurala språk (PL/pgSQL, T-SQL, PL/SQL — minskad portabilitet), är svårare att felsöka, och lägger belastning på databaslagret (ofta det svåraste att skala).

Av dessa anledningar **favoriserar modern applikationsutveckling ofta att hålla affärslogik i applikationslagret** (testbar, portabel, versionskontrollerad) snarare än i lagrade procedurer.

Nyckelinsikten är **bedömningen av när man ska använda dem** — lämpligt för specifika prestandakritiska eller databasnivå-tvingande behov, men generellt undvikna som standard för affärslogik.

Eftersom lagrade procedurer är vanliga i många system (särskilt enterprise/legacy), och eftersom förståelse av både deras fördelar och deras avvägningar (och den moderna lutningen mot applikationslagrets logik) är vad som möjliggör sunda arkitekturbeslut, är förståelse av lagrade procedurer värdefull seniorkunskap som demonstrerar förmågan att väga databasisk kontra applikationssidans logik — en meningsfull designöverväägelse och ett ämne som reflekterar arkitektonisk mognad.