Wat zijn stored procedures en wanneer moet je ze gebruiken?

Question

Accepted Answer

Een **stored procedure** is een set SQL-statements (en procedurele logica) opgeslagen in de database en uitgevoerd op naam. Het voert logica *binnen* de database uit in plaats van in toepassingscode. Ze hebben echte voordelen maar ook significante afwegingen, dus wanneer je ze moet gebruiken is een echte ontwerpbeslissing.

## Een stored 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
```

Een stored procedure bundelt SQL en procedurele logica (variabelen, voorwaarden, loops, foutafhandeling) in een benoemde, herbruikbare databaseroutine. Functies zijn vergelijkbaar maar retourneren een waarde.

## Potentiële voordelen

```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 significante afwegingen (waarom veel mensen ze vandaag vermijden)

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

## Wanneer je ze moet gebruiken

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

## Waarom het belangrijk is

Stored procedures begrijpen — inclusief hun afwegingen — is waardevol omdat ze een echte architectuurbeslissing vertegenwoordigen met echte voordelen en echte nadelen, en weten *wanneer* je ze moet gebruiken (en wanneer niet) weerspiegelt rijpheid in oordeel.

Stored procedures kunnen **prestatiewinsten** bieden (het uitvoeren van multi-staps logica in de database vermijdt netwerkrondes), verminderde netwerkverkeer, herbruikbaarheid over clients, beveiliging (execute-toestemming geven zonder tabeltoegang), en gecentraliseerde consistentie — waardoor ze geschikt zijn voor performance-kritieke data-intensieve operaties, batchverwerking, en logica die op databaseniveau moet worden afgedwongen over meerdere toepassingen.

Het begrijpen van de **significante afwegingen** is echter even belangrijk en weerspiegelt moderne praktijk: het plaatsen van bedrijfslogica in de database maakt het moeilijker versiecontroleren, testen en onderhouden (logica splitsen tussen app en database), bindt je aan de procedurele taal van een specifieke database (PL/pgSQL, T-SQL, PL/SQL — verminderde portabiliteit), is moeilijker voor debugging, en voegt belasting toe aan de databasetier (meestal het moeilijkst om schaal aan te passen).

Om deze redenen **favoriete moderne applicatieontwikkeling het houden van bedrijfslogica in de applicatielaag** (testbaar, draagbaar, versiebeheerd) in plaats van in stored procedures.

De kernstelling is het **oordeel over wanneer je ze moet gebruiken** — geschikt voor specifieke performance-kritieke of DB-niveau-afhandelingsvereisten, maar over het algemeen vermeden als standaard voor bedrijfslogica.

Omdat stored procedures veel voorkomen in veel systemen (vooral enterprise/legacy), en omdat het begrijpen van beide hun voordelen en hun afwegingen (en de moderne voorkeur voor applicatielaaglogica) is wat gezonde architectuurbeslissingen mogelijk maakt, is het begrijpen van stored procedures waardevol kennis op senior niveau dat het vermogen aantoont om databasezijde versus applicatielaaglogica af te wegen — een betekenisvolle ontwerpoverwegeing en een onderwerp dat architecturale rijpheid weerspiegelt.