Warum Trigger selten trivial sind
Viele Assessments zählen Trigger nur als Objekt. Das reicht nicht. Entscheidend ist, ob der Trigger nur technische Hilfsarbeit leistet oder fachliche Logik ausführt, die nach der Migration dieselbe Semantik behalten muss.
Typische Trigger-Klassen
| ID-Trigger | Meist durch Identity Columns oder Sequenzen ersetzbar. |
| Audit-Trigger | Kann in PostgreSQL bleiben, muss aber Transaktions- und Fehlerverhalten prüfen. |
| Validierungs-Trigger | Teilweise durch Constraints ersetzbar, teilweise Anwendungsthema. |
| Historisierung | Benötigt Zielkonzept für Änderungsprotokolle, Zeiträume und Löschlogik. |
| DML auf Nebentabellen | Hohes Risiko, weil Seiteneffekte und Reihenfolge wichtig werden. |
PostgreSQL-Zieloptionen
- Constraints: für einfache Regeln und referenzielle Integrität.
- Generated Columns: für berechenbare Werte, wenn passend.
- PL/pgSQL Trigger: für datenbanknahe Logik mit klarem Umfang.
- Anwendungsschicht: für fachliche Prozesslogik und komplexe Workflows.
- Event-/Queue-Mechanismen: für entkoppelte Folgeaktionen.
Risikobewertung
Ein Trigger mit einer einfachen Sequence-Zuweisung ist meist niedriges Risiko. Ein Trigger, der mehrere Tabellen verändert, externe Pakete aufruft oder Fehler unterdrückt, ist ein Migrationsrisiko. Besonders kritisch sind Trigger mit WHEN OTHERS THEN NULL, dynamischem SQL oder Abhängigkeiten zu Packages.
Assessment-Empfehlung
GCON-DB klassifiziert Trigger nach Zweck, Komplexität, DML-Seiteneffekten und Zielstrategie. Das Ergebnis ist keine pauschale Konvertierung, sondern eine Entscheidung: Constraint, PostgreSQL-Trigger, Anwendungscode oder Redesign.
FAQ
Können Oracle Trigger direkt nach PostgreSQL übertragen werden?
Einfache Trigger oft ja. Fachliche Triggerlogik muss vorher analysiert werden, weil PostgreSQL zwar Trigger unterstützt, aber nicht automatisch dieselbe Architektur erzwingt.
Sind Trigger ein hohes Migrationsrisiko?
Ja, sobald sie Businesslogik, Nebentabellen-DML, dynamisches SQL oder Package-Aufrufe enthalten.
Sollte man Trigger bei der Migration entfernen?
Nicht pauschal. Technische Trigger können bleiben, fachliche Prozesslogik gehört häufig besser in Anwendung oder Services.