Warum Packages kritisch sind
Ein Oracle Package ist nicht nur eine Sammlung von Procedures und Functions. Es kann globale Variablen, Initialisierungscode, Session State, fachliche Servicestrukturen und technische Hilfsfunktionen enthalten.
Typische Package-Muster
- fachliche Services wie
order_pkg,billing_pkgodercustomer_pkg - technische Utility Packages
- Batch- und Importlogik
- Validierungslogik
- Logging und Audit
- Schnittstellenlogik zu Dateien, HTTP oder Fremdsystemen
Package State ist ein Warnsignal
Globale Package-Variablen können Session State halten. Dieses Verhalten ist in PostgreSQL nicht als direktes Package-Konzept vorhanden. In einer Migration muss entschieden werden, ob State in Tabellen, Anwendungssessions, Services oder expliziten Parametern geführt wird.
Mögliche Zielbilder
| PL/pgSQL Funktionen | Für einfache, datenbanknahe Logik. |
| Schema-Namensräume | Für organisatorische Struktur, aber nicht als vollständiger Package-Ersatz. |
| Anwendungsservice | Für fachliche Logik, Workflows und Schnittstellen. |
| Temporärer Oracle-Verbleib | Für komplexe Legacy-Logik im Wellenmodell. |
Assessment-Kriterien
Bewertet werden Lines of Code, Anzahl öffentlicher Routinen, Abhängigkeiten, globale Variablen, DBMS_-Nutzung, dynamisches SQL und fachliche Kopplung zur Anwendung.
Packages sollten nicht automatisch nach PL/pgSQL gedrückt werden. Die bessere Frage lautet: Welche Verantwortung hat dieses Package fachlich?
FAQ
Gibt es Packages in PostgreSQL?
Nicht im gleichen Sinn wie in Oracle. PostgreSQL bietet Schemas und Funktionen, aber kein identisches Package-Konzept mit Package Specification, Body und State.
Wie migriert man Package State?
Meist durch Redesign: Anwendungssession, explizite Parameter, Tabellen oder Services. Eine blinde 1:1-Migration ist riskant.
Sind Utility Packages einfach?
Häufig ja, sofern sie keine Oracle-spezifischen APIs, globalen Zustände oder externen Abhängigkeiten nutzen.