Unterprogramme in SQL gibt es in zwei Arten:
CALL/EXEC aufgerufen und werden nicht immer in der SELECT-Schicht verwendet.Wichtig:
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;
Kann man eine Stored Procedure direkt in SELECT verwenden?
Oft antworten die Leute mit "ja", aber das ist falsch.
Antwort:
EXEC/CALL), jedoch können Funktionen in SELECT verwendet werden.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).