| Dynamisches SQL mit REF Cursor |
|
|
| Mittwoch, 21. Januar 2009 um 19:32 | ||||
Was ist ein REF CURSOR?Nun, wir haben die "normalen" Cursor kennengelernt. Sie werden deklariert und dabei wird ihnen ein statisches SQL-Statement zugewiesen (das parametrisiert werden kann). Der Cursor ist dabei ein Pointer auf einen Speicherbereich, in dem die selektierten Daten liegen.
Ein REF Cursor hingegen ist ein Pointer auf einen Speicherbereich, in dem die selektierten Datensätze liegen.
Der Benefit führt zu mehr Transparenz und Kapselung für den Aufrufer. Der Aufrufer erhält einen Pointer auf einen Speicherbereich, von dem er nicht weiss (wissen muss), wie die darin enthaltenen Datensätze tatsächlich ermittelt worden sind (Ortstransparenz, Kapselung). Gleichzeitig hat der Aufrufer die eigene Entscheidungskompetenz, wieviel Daten er tatsächlich aus dem Cursor abrufen will, bzw. wie er ihn bearbeiten will. Beispiel 1: Nehmen wir an, eine Funktion hat die Aufgabe, Mitarbeiter aus der EMP-Tabelle an einen Aufrufer zurückzureichen. Natürlich kann die Funktion eine gefüllte PL/SQL-Tabelle zurückreichen, die entsprechend der Parametrisierung (z.B. nur eine bestimmte Abteilung) gefüllt ist. Nachteil: Der Speicherbedarf wächst (vielleicht gibt es 1000 Mitarbeiter in einer Abteilung, PL/SQL benötigt dann eine große Variable), obwohl der Aufrufer nur bestimmte Mitarbeiter aus der Abteilung braucht. Blöd. Beispiel 2: Der Aufrufer benötigt Daten und die aufgerufene Funktion muss entscheiden, woher diese Daten zu beschaffen sind. Die Funktion bestimmt das SELECT-Statement und damit die zu lesende Tabelle oder sogar das Schema und liefert dem Aufrufer einen Pointer auf diese Datenmenge zurück. Der Aufrufer hat keine Ahnung, woher die Daten stammen, er benutzt sie lediglich. Sie müssen sich registrieren, um den Artikel ganz zu lesen
|
||||
| Aktualisiert ( Dienstag, 13. Oktober 2009 um 16:36 ) | ||||

