Was sind Stored Procedures und wann solltest du sie verwenden?

Question

Accepted Answer

Eine **Stored Procedure** ist eine Menge von SQL-Anweisungen (und prozeduraler Logik), die in der Datenbank gespeichert und nach Name ausgeführt wird. Sie führt Logik *innerhalb* der Datenbank aus, anstatt in Anwendungscode. Sie haben echte Vorteile, aber auch erhebliche Kompromisse, daher ist die Frage, wann sie verwendet werden sollten, eine echte Designentscheidung.

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

Eine Stored Procedure bündelt SQL und prozedurale Logik (Variablen, Bedingungen, Schleifen, Fehlerbehandlung) in eine benannte, wiederverwendbare Datenbankroutine. Funktionen sind ähnlich, geben aber einen Wert zurück.

## Potenzielle Vorteile

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

## Die erheblichen Kompromisse (warum viele sie heute vermeiden)

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

## Wann man sie verwenden sollte

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

## Warum es wichtig ist

Das Verständnis von Stored Procedures — einschließlich ihrer Kompromisse — ist wertvoll, da sie eine echte architektonische Wahl mit echten Vorteilen und echten Nachteilen darstellen, und zu wissen, *wann* man sie einsetzt (und wann nicht), zeigt reifes Urteilsvermögen.

Stored Procedures können **Performance-Vorteile** bieten (das Ausführen von mehrstufiger Logik innerhalb der Datenbank vermeidet Netzwerk-Roundtrips), reduzieren Netzwerkverkehr, ermöglichen Wiederverwendung über mehrere Clients, erhöhen Sicherheit (Ausführungsberechtigung ohne Tabellenzugriff) und zentralisieren Konsistenz — was sie für Performance-kritische datenintensive Operationen, Batch-Verarbeitung und Logik geeignet macht, die datenbankweit über mehrere Anwendungen durchgesetzt werden muss.

Jedoch ist das Verständnis der **erheblichen Kompromisse** gleich wichtig und spiegelt moderne Praktiken wider: Das Platzieren von Geschäftslogik in der Datenbank macht es schwieriger zu versionieren, zu testen und zu warten (Logik wird zwischen App und Datenbank aufgeteilt), bindet dich an die prozedurale Sprache einer bestimmten Datenbank (PL/pgSQL, T-SQL, PL/SQL — reduziert Portabilität), ist schwieriger zu debuggen und erhöht die Last auf der Datenbank-Ebene (oft am schwierigsten zu skalieren).

Aus diesen Gründen **bevorzugt moderne Anwendungsentwicklung oft, die Geschäftslogik in der Anwendungsschicht zu halten** (testbar, portabel, versionskontrolliert), anstatt in Stored Procedures.

Der Schlüsseleinblick ist das **Urteilsvermögen, wann man sie einsetzt** — geeignet für spezifische Performance-kritische oder DB-Ebenen-Durchsetzungsanforderungen, aber generell als Standard für Geschäftslogik vermieden.

Da Stored Procedures in vielen Systemen verbreitet sind (besonders in Enterprise/Legacy), und da das Verständnis sowohl ihrer Vorteile als auch ihrer Kompromisse (und die moderne Ausrichtung auf Anwendungsschicht-Logik) es ermöglicht, solide architektonische Entscheidungen zu treffen, ist das Verständnis von Stored Procedures wertvollseniores Wissen, das die Fähigkeit demonstriert, datenbankgestützte versus anwendungsgestützte Logik abzuwägen — eine bedeutungsvolle Designüberlegung und ein Thema, das architektonische Reife widerspiegelt.