Hallo Community,
ich habe ein Problem, und benötige dringend eine Lösung.
Wir verwenden mit ca. 10 Kollegen eine Tabelle die ca. 100 Spalten hat. In dieser Tabelle befindet sich eine gewisse Anzahl von Datensätzen (ca. 23. Millionen), die über eine ID eindeutig identifiziert werden können.
Nun ist es nötig, dass wir mit verschiedenen PL/SQL Skripten in einer entsprechenden Spalte ein Update durchführen. Die dahinter liegende Logik (welche Datensätze sollen aktualisiert werden und mit welchem Werte) ist dabei von Skript zu Skript unterschiedlich.
Um Fehler zu vermeiden, möchte ich nun eine Standardvorlage als PL/SQL Skript entwickeln, die wir gemeinsam verwenden. Diese Vorlage hat im Kopf (DECLARE) einen Konfigurationsteil (hier gibt man z.B. eine Konstante an, die den Spaltennamen beschreibt in die geschrieben werden soll). Im BEGIN-Teil kommt dann ein MERGE-Befehl, dessen Source-SQL vom jeweiligen Entwickler mit seinem Speziellen SQL befüllt wird. Dieser SQL muss nun zwei Werte liefern, zum einen die eindeutige ID des zu aktualisierenden Datensatzes und den Wert, der in die gewünschte Spalte (Konstante im Konfigurationsteil) geschrieben werden soll.
Hier mal eine abgespeckte Version meines Vorlagenskriptes:
Der SQL zwischen den gestrichelten Linien ist genau der, der vom jeweiligen Programmierer eingesetzt werden soll. In diesem Beispiel hier ist er sehr schlicht gehalten, kann aber in der Realität durchaus sehr komplex (mehrere hundert Zeilen) lang werden.
Das Kernproblem ist nun, dass die Zielspalte (im Code-Beispiel hier "MEINESPALTE_5") ganz unten im Code noch einmal aufgerufen wird:
Es ist mir jetzt nicht ohne weiteres möglich, hier die oben festgelegte Konstante "CS_SPALTE" zu verwenden um die Zielspalte zu definieren.
Dadurch besteht jedoch das Risiko, dass ein Entwickler es einfach mal vergisst, diese Zeile am Ende des Skriptes anzupassen, und somit ggf. die Berechnungsergebnisse eines anderen Kollegen (in einer anderen Spalte) zu zerschießen. (Leider kommt es bei uns öfters vor, dass man sich andere Skripte von Kollegen oder von sich selbst als Vorlage nimmt, und diese dann für seine Zwecke entsprechend anpasst).
Um dieses Risiko zu minimieren, würde ich gern im Konfigurationsbereich oben festlegen, welche Spalte in der Zieltabelle dieses Skript beschreiben darf. Die manuelle Anpassung in der unteren Zeile des Merges würde ich mir gern sparen.
Aufgrund der Komplexität des jeweiligen Berechnungs-SQL's, der zwischen den beiden gestrichelten Linien in dieser Vorlage eingesetzt werden kann (hier werden z.B. häufig unter anderem weitere Variablen und Konstanten verwendet), scheidet eine Ausführung durch einen EXECUTE IMMEDIATE leider aus. Das Syntax-Highlightning wird dadurch außerdem komplett ausgehebelt, was der Übersichtlichkeit nicht hilft.
Hat hier ein schlauer Kopf vielleicht eine Lösung für mein Problem? Ich bin auch gern offen für andere Ansätze...
ich habe ein Problem, und benötige dringend eine Lösung.
Wir verwenden mit ca. 10 Kollegen eine Tabelle die ca. 100 Spalten hat. In dieser Tabelle befindet sich eine gewisse Anzahl von Datensätzen (ca. 23. Millionen), die über eine ID eindeutig identifiziert werden können.
Nun ist es nötig, dass wir mit verschiedenen PL/SQL Skripten in einer entsprechenden Spalte ein Update durchführen. Die dahinter liegende Logik (welche Datensätze sollen aktualisiert werden und mit welchem Werte) ist dabei von Skript zu Skript unterschiedlich.
Um Fehler zu vermeiden, möchte ich nun eine Standardvorlage als PL/SQL Skript entwickeln, die wir gemeinsam verwenden. Diese Vorlage hat im Kopf (DECLARE) einen Konfigurationsteil (hier gibt man z.B. eine Konstante an, die den Spaltennamen beschreibt in die geschrieben werden soll). Im BEGIN-Teil kommt dann ein MERGE-Befehl, dessen Source-SQL vom jeweiligen Entwickler mit seinem Speziellen SQL befüllt wird. Dieser SQL muss nun zwei Werte liefern, zum einen die eindeutige ID des zu aktualisierenden Datensatzes und den Wert, der in die gewünschte Spalte (Konstante im Konfigurationsteil) geschrieben werden soll.
Hier mal eine abgespeckte Version meines Vorlagenskriptes:
Code:
DECLARE
-- Konfiguration (Konstanten festlegen)
CS_SPALTE CONSTANT VARCHAR2(7) := 'MEINESPALTE_5';
BEGIN
MERGE INTO MEINSCHEMA.MEINEZIELTABELLE D
USING
(
----------------------------------------------------------------
SELECT ID,
NEUER_WERT
FROM ANDERE_TABELLE
----------------------------------------------------------------
) S
ON (
D.ID = S.ID
)
WHEN MATCHED THEN UPDATE SET D.MEINESPALTE_5 = S.KPI
;
COMMIT;
END;
/Der SQL zwischen den gestrichelten Linien ist genau der, der vom jeweiligen Programmierer eingesetzt werden soll. In diesem Beispiel hier ist er sehr schlicht gehalten, kann aber in der Realität durchaus sehr komplex (mehrere hundert Zeilen) lang werden.
Das Kernproblem ist nun, dass die Zielspalte (im Code-Beispiel hier "MEINESPALTE_5") ganz unten im Code noch einmal aufgerufen wird:
Code:
WHEN MATCHED THEN UPDATE SET D.MEINESPALTE_5 = S.KPIEs ist mir jetzt nicht ohne weiteres möglich, hier die oben festgelegte Konstante "CS_SPALTE" zu verwenden um die Zielspalte zu definieren.
Dadurch besteht jedoch das Risiko, dass ein Entwickler es einfach mal vergisst, diese Zeile am Ende des Skriptes anzupassen, und somit ggf. die Berechnungsergebnisse eines anderen Kollegen (in einer anderen Spalte) zu zerschießen. (Leider kommt es bei uns öfters vor, dass man sich andere Skripte von Kollegen oder von sich selbst als Vorlage nimmt, und diese dann für seine Zwecke entsprechend anpasst).
Um dieses Risiko zu minimieren, würde ich gern im Konfigurationsbereich oben festlegen, welche Spalte in der Zieltabelle dieses Skript beschreiben darf. Die manuelle Anpassung in der unteren Zeile des Merges würde ich mir gern sparen.
Aufgrund der Komplexität des jeweiligen Berechnungs-SQL's, der zwischen den beiden gestrichelten Linien in dieser Vorlage eingesetzt werden kann (hier werden z.B. häufig unter anderem weitere Variablen und Konstanten verwendet), scheidet eine Ausführung durch einen EXECUTE IMMEDIATE leider aus. Das Syntax-Highlightning wird dadurch außerdem komplett ausgehebelt, was der Übersichtlichkeit nicht hilft.
Hat hier ein schlauer Kopf vielleicht eine Lösung für mein Problem? Ich bin auch gern offen für andere Ansätze...
