ProgrammierungDatenbankentwickler / DB-Architekt

Wie erstellt und verwendet man Unterprogramme (Procedure/Function) in SQL richtig, um wiederverwendbare Geschäftslogik zu implementieren, und welche Feinheiten gibt es bei der Handhabung von Parametern und Rückgabewerten?

Bestehen Sie Vorstellungsgespräche mit dem Hintsage-KI-Assistenten

Antwort.

Unterprogramme in SQL gibt es in zwei Arten:

  • Prozeduren (Stored Procedures): führen Aktionen aus (Einfügen, Aktualisieren, Löschen), können OUT-Parameter oder Ergebnismengen (durch SELECT) zurückgeben. Sie werden mit CALL/EXEC aufgerufen und werden nicht immer in der SELECT-Schicht verwendet.
  • Funktionen (User Defined Functions, UDF): geben einen Wert zurück (skalar oder tabellarisch), können direkt in SELECT, WHERE, ORDER BY und anderen Konstruktionen verwendet werden.

Wichtig:

  • Prozeduren können NICHT in einem normalen SELECT verwendet werden, nur durch den Aufruf mit EXEC/CALL.
  • Funktionen können nur einen Wert (skalar) oder eine Tabelle (tabellarische Funktionen) zurückgeben und können in jedem Ausdruck verwendet werden.
  • Dokumentieren Sie immer die Parameter: IN (für Eingaben), OUT (für Rückgabeergebnisse), INOUT (zweiwege).

Beispiel einer skalaren Funktion (PostgreSQL):

CREATE FUNCTION get_tax(amount NUMERIC, rate NUMERIC DEFAULT 0.13) RETURNS NUMERIC AS $$ BEGIN RETURN amount * rate; END; $$ LANGUAGE plpgsql; -- Verwendung: SELECT *, get_tax(price) AS tax FROM product;

Beispiel einer Stored Procedure (SQL Server):

CREATE PROCEDURE add_employee(@name NVARCHAR(100), @salary INT, @emp_id INT OUTPUT) AS BEGIN INSERT INTO employees (name, salary) VALUES (@name, @salary); SET @emp_id = SCOPE_IDENTITY(); END; DECLARE @id INT; EXEC add_employee 'John', 100000, @id OUTPUT;

Fangfrage.

Kann man eine Stored Procedure direkt in SELECT verwenden?

Oft antworten die Leute mit "ja", aber das ist falsch.

Antwort:

  • Nein: Standardprozeduren werden nur separat aufgerufen (EXEC/CALL), jedoch können Funktionen in SELECT verwendet werden.

Beispiele echter Fehler aufgrund mangelnden Wissens über die Feinheiten des Themas.


Geschichte

Projekt: System für die Primärbuchhaltung, Implementierung von Berichten. Fehler: Anstelle einer Funktion wurde eine Prozedur zur Berechnung der Summe geschrieben –SELECT funktionierte nicht, die gesamte Logik der Benutzerberichte musste neu geschrieben werden.


Geschichte

Projekt: ERP-System mit externen Parametern. Fehler: Für die Prozedur wurde der OUT-Schlüssel nicht gesetzt, sodass der Kunde die ID des hinzugefügten Datensatzes nicht erfahren konnte, die Integration "brach zusammen".


Geschichte

Projekt: Finanzdienstleistung mit Steuerberechnungen nach verschiedenen Regeln. Fehler: Eine skalare Funktion wurde in einer Massenabfrage ohne Leistungstest verwendet – die Abfrage verlangsamte die Verarbeitung der Tabelle aufgrund der zeilenweisen Aufruf (nicht optimierter Plan).