In Reporting-Anwendungen taucht dieselbe fachliche Abfrage oft an mehreren Stellen auf: dieselben Spalten, Joins und Filter, aber mit jeweils anderen Parametern. Ein SQL Table Macro kapselt diese Abfragelogik in einer Funktion, die in der FROM-Klausel wie eine Tabelle verwendet werden kann. Oracle erweitert das Macro zu SQL; die Datenverarbeitung bleibt damit Teil der aufrufenden SQL-Abfrage.
Ein kleines, parametrisierbares Beispiel
Angenommen, das Schema HR benötigt die Mitarbeiter eines Bereichs regelmäßig in Reports. Ein Table Macro kann den Filter zentral bereitstellen:
CREATE OR REPLACE FUNCTION employees_by_dept (
p_deptno NUMBER
) RETURN VARCHAR2 SQL_MACRO(TABLE)
IS
BEGIN
RETURN q'{
SELECT e.employee_id,
e.first_name,
e.last_name,
e.department_id
FROM employees e
WHERE e.department_id = employees_by_dept.p_deptno
}';
END;
/Danach lässt sich die Funktion wie eine Tabellenquelle aufrufen und mit weiteren SQL-Klauseln kombinieren:
SELECT employee_id, last_name
FROM employees_by_dept(50)
WHERE last_name LIKE 'A%'
ORDER BY last_name;Die Makrofunktion erzeugt den SQL-Ausdruck; sie liefert nicht zeilenweise selbst Daten zurück. Das macht sie nützlich, um gemeinsame Abfrageformen zentral zu halten und trotzdem Joins, zusätzliche Filter und Projektionen beim Aufrufer zu ermöglichen.
Wann ein Macro sinnvoll ist
Table Macros sind eine Option für wiederkehrende, parametrisierbare Tabellenabfragen – etwa standardisierte Reporting-Sichten mit wechselnden Filtern. Eine normale View ist einfacher, wenn keine Parameter nötig sind. Eine polymorphe Table Function passt eher, wenn Zeilen tatsächlich prozessiert oder die Ausgabespalten zur Laufzeit beschrieben werden müssen.
Das Macro sollte SQL-Text nicht aus ungeprüften Nutzereingaben zusammensetzen. Werte gehören als Macro-Argumente in die SQL-Expression; beliebige Identifier oder SQL-Fragmente erfordern eine bewusst abgesicherte Lösung. Beachten Sie auch die Privilegien: In Views wird ein SQL Macro mit den Rechten des View-Eigentümers verarbeitet. Definer-/Invoker-Verhalten und benötigte INHERIT PRIVILEGES sollten daher vor einem zentralen Schema-Rollout geprüft werden.
Grenzen und Test
SQL Macros müssen einen Zeichenketten-Typ (VARCHAR2, CHAR oder CLOB) zurückgeben. Ein Table Macro darf in einer Tabellenexpression der FROM-Klausel stehen; es ist kein Drop-in-Ersatz für jede Funktion. Vor dem Einsatz sollten Teams den expandierten SQL-Text, Ausführungsplan, Berechtigungen und Ergebnisse für mehrere Parameterwerte prüfen. Ein Macro verbessert nicht automatisch den Plan – es standardisiert primär die Abfragekonstruktion.
Fazit
SQL Table Macros verbinden wiederverwendbare Abfragelogik mit der Flexibilität von SQL. Sie lohnen sich, wenn eine fachliche Tabellenexpression an vielen Stellen identisch bleiben soll, aber weiterhin mit der umgebenden Abfrage komponierbar sein muss. Klare Argumente, keine ungeprüfte SQL-String-Konkatenation und ein Rechte- sowie Plan-Test gehören dazu.
Weiterführend: Oracles Referenz zur SQL_MACRO-Klausel und zur CREATE FUNCTION-Anweisung.