Oracle Datenbank / Stored Procedures

Viele Legacy-Systeme enthalten einen grossen Teil ihrer Fachlogik in Stored Procedures, Packages, Triggern, Views und Datenkorrekturskripten. Das ist nicht automatisch schlecht: Datenbanklogik kann sehr stabil, performant und transaktional konsistent sein.

Problematisch wird es, wenn Anwendungscode und Datenbanklogik denselben fachlichen Zustand aus unterschiedlichen Perspektiven veraendern. Dann entstehen schwer testbare Seiteneffekte: Trigger setzen Status, Packages korrigieren Beträge, Views verstecken Filterregeln.

Modernisierung beginnt mit Dateninventar und Regelkatalog. Danach kann man entscheiden, welche Regeln in der Datenbank bleiben, welche in Services wandern und wo ein Parallelbetrieb mit Vergleichsabfragen notwendig ist.

1. Anwendung ruft Procedure oder schreibt Tabelle.
2. Constraints und Trigger validieren oder veraendern Daten.
3. Package fuehrt Berechnung, Statuswechsel oder Buchungslogik aus.
4. Views und Materialized Views stellen Daten fuer Reporting bereit.
5. ETL oder Batch liest Daten fuer DWH, Archiv oder Partnerausleitung.

Die Beispiele sind bewusst nicht minimalistisch. Sie zeigen typische Artefakte, die man in echten Legacy-Analysen findet: Schnittstellenverträge, Containerkonfiguration, SQL/PL-SQL, Jobdefinitionen, Queue-Regeln oder Adaptercode.

CREATE OR REPLACE PACKAGE billing_rules AS
  PROCEDURE approve_invoice(p_invoice_id IN NUMBER, p_user IN VARCHAR2);
  FUNCTION calculate_tax(p_net_amount IN NUMBER, p_country IN VARCHAR2) RETURN NUMBER;
END billing_rules;
/
CREATE OR REPLACE PACKAGE BODY billing_rules AS
  PROCEDURE approve_invoice(p_invoice_id IN NUMBER, p_user IN VARCHAR2) IS
    v_status VARCHAR2(20);
  BEGIN
    SELECT status INTO v_status FROM invoice WHERE id = p_invoice_id FOR UPDATE;
    IF v_status <> 'READY' THEN
      RAISE_APPLICATION_ERROR(-20010, 'Invoice is not ready for approval');
    END IF;
    UPDATE invoice SET status = 'APPROVED', approved_by = p_user, approved_at = SYSTIMESTAMP
    WHERE id = p_invoice_id;
  END;
  FUNCTION calculate_tax(p_net_amount IN NUMBER, p_country IN VARCHAR2) RETURN NUMBER IS
  BEGIN
    RETURN CASE WHEN p_country = 'AT' THEN p_net_amount * 0.20 ELSE p_net_amount * 0.19 END;
  END;
END billing_rules;

CREATE OR REPLACE TRIGGER trg_invoice_status_hist
AFTER UPDATE OF status ON invoice
FOR EACH ROW
BEGIN
  INSERT INTO invoice_status_history(invoice_id, old_status, new_status, changed_at)
  VALUES (:OLD.id, :OLD.status, :NEW.status, SYSTIMESTAMP);
END;

public class InvoiceApprovalRepository {
    private final DataSource dataSource;

    public void approve(long invoiceId, String user) throws SQLException {
        try (Connection con = dataSource.getConnection();
             CallableStatement st = con.prepareCall("{call billing_rules.approve_invoice(?, ?)}")) {
            st.setLong(1, invoiceId);
            st.setString(2, user);
            st.execute();
        }
    }
}

• Wer besitzt fachlich die Wahrheit fuer Kundenbestand?
• Welche technische Komponente ist kritisch: Oracle, PL/SQL, Packages?
• Welche Daten werden veraendert, gelesen, abgeleitet oder nur transportiert?
• Welche Fehler sind fachlich erwartbar und welche sind technische Stoerungen?
• Welche Protokolle, Dateien, Tabellen, Queues oder Reports bilden den offiziellen Vertrag?
• Wie wird ein Fehler heute erkannt, korrigiert und gegenueber dem Fachbereich nachgewiesen?
• Welche Teile lassen sich lesend modernisieren und welche sind schreibend hochkritisch?
• Welche Tests sichern aktuelles Verhalten, bevor Refactoring oder Migration beginnt?

Suche in einer fiktiven Datenbank alle Trigger und Packages rund um Rechnung. Ordne sie fachlichen Regeln zu. Entscheide pro Regel: bleibt in DB, wird gekapselt, wird getestet oder wandert in Application Service.