Im Kern wird die schnellere Ausfuehrung der Query dadurch realisiert, dass mittels der WITH-Klausel die Ergebnismenge der Subquery vorab materialisiert, mit einem Namen versehen und schliesslich in der Hauptquery abgegriffen wird.
Hier lohnt sich auch ein Vergleich und Gebrauch von "global temporary tables", die in Ihrer Funktions- und Wirkungsweise durchaus ähnlich sind:
Durch Entkopplung geeigneter Subqueries, die urspruenglich als Bestandteile einer komplexen Abfrage fungierten, wird dieses SQL-Statement vereinfacht.

WITH   SQ1 AS (SELECT...FROM...WHERE...),
       SQ2 AS (SELECT...FROM...WHERE...)
SELECT...
  FROM Q1, SQ1, SQ2 WHERE…

Interessanter Nebeneffekt:

Durch die Verwendung der WITH-Klausel wird anscheinend in einer Systemumgebung mit voreingestelltem CURSOR_SHARING=FORCE offensichtlich fuer die Query-Ausfuehrung diese systemweit gueltige Einstellung auf CURSOR_SHARING=EXACT zurueckgenommen (vergleichbar dem Einsatz des Hint /*+ cursor_sharing_exact */).

Zeigen die QEPs vorher noch eine allgemeine Ersetzung von Konstanten durch Parameter, so weisen die QEPs nachher die direkte Verwendung der Konstanten auf.

Somit orientiert sich der Optimizer auch grundsaetzlich an anderen Zugriffsstrategien.

Was in einer Umgebung mit problematischem Parseverhalten per Bindvariablen-Peeking einen "flüssigen" Anwendungsbetrieb ermöglichen kann, wird im Einzelfall einer komplexen Query unter Verwendung von Attributen mit stark ungleicher Werteverteilung zu relativ kostenintensiven QEPs führen.

Es empfiehlt sich dann für alle entsprechenden Konstanten/Parameter einen separaten und speziellen QEP zu erzwingen.

Vorraussetzung:

SQL-99 Standard bzw. Oracle9i Release 2

Links:

SQLStandards.html

to be continued….

Komplette Ausarbeitung: QT-check-constraint-vs-trigger

Die meisten ermitteln den Inhalt einer Spalte ganz Normal über eine Cursor-Programmierung innerhalb einer Funktion. Das bedeutet, dass für jede Spalte, die ermittelt werden soll, eine Funktion geschrieben wird. Dies erzeugt unnötigen Sourcecode.

Ein weiterer Vorteil ist das cachen des Records. Ändert sich die ID nicht, so braucht der Record nicht noch mal via Cursor gelesen werden, sondern kann direkt zurück gegeben werden. Das kann die Performance (> 50%) unter Umständen ziemlich steigern.

Ein effektiverer Weg ist folgender:

1. Aufsetzten eines "get"-Package für die jeweiligen Tabellen.
2. Implementierung einer zentralen "privaten" get-Routine
3. Implementierung der jeweils benötigten "öffentlichen" get-Routinen.

Beispiel:

Tabelle: WARENGRUPPEN

Auszug der Spalten der Tabelle

• wag_id NUMBER(10,0)
• wag_bezeichnung VARCHAR2(100)
• wag_kontonr NUMBER(10,0)
• wag_status NUMBER(1,0)

PACKAGE pgk_wag IS
   FUNCTION get_bezeichnung(pi_id warengruppen.wag_id%TYPE) RETURN warengruppen.wag_bezeichnung%TYPE;    FUNCTION get_kontonr(pi_id warengruppen.wag_id%TYPE) RETURN warengruppen.wag_kontonr%TYPE;    FUNCTION get_status(pi_id warengruppen.wag_id%TYPE) RETURN warengruppen.wag_status%TYPE;
END pkg_wag;

PACKAGE BODY pgk_wag IS

   g_id warengruppen.id%TYPE;<br />   g_record warengruppen%ROWTYPE;<br />&#160;&#160;&#160; FUNCTION get(pi_id warengruppen.wag_id%TYPE)
            RETURN warengruppen.wag_bezeichnung%TYPE IS&#160;&#160;&#160;&#160; CURSOR c_rec IS
      SELECT *
        FROM warengruppen
       WHERE wag_id = pi_id;
 
BEGIN<br />   IF pi_id &lt;&gt; g_id THEN<br />      g_id := pi_id;<br />
      OPEN c_rec;&#160;&#160;&#160; FETCH c_rec INTO g_record;
      CLOSE c_rec;<br />   END IF;&#160;&#160;&#160; RETURN g_record;
END get;
 
FUNCTION get_bezeichnung(pi_id warengruppen.wag_id%TYPE)
         RETURN warengruppen.wag_bezeichnung%TYPE;&#160;&#160;&#160; BEGIN&#160;&#160;&#160;&#160;&#160;&#160; RETURN get(pi_id).wag_bezeichnung;&#160;&#160;&#160; END get_bezeichnung;
 
FUNCTION get_kontonr(pi_id warengruppen.wag_id%TYPE)
         RETURN warengruppen.wag_kontonr%TYPE;&#160;&#160;&#160; BEGIN&#160;&#160;&#160;&#160;&#160; RETURN get(pi_id).wag_kontonr;&#160;&#160;&#160; END get_kontonr;
 
FUNCTION get_status(pi_id warengruppen.wag_id%TYPE)
         RETURN warengruppen.wag_status%TYPE;&#160;&#160;&#160; BEGIN&#160;&#160;&#160;&#160;&#160;&#160; RETURN get(pi_id).wag_status;&#160;&#160;&#160; END get_status;<br /><br /><br />
BEGIN<br />   g_id := -1;  -- Initialisierung der Globalen Hilfsvariable    <br />END pkg_wag;

Vorteil

Das Package ist schnell erweiterbar und sehr übersichtlich.

Nachteil

Man muss bedenken, dass immer eine Selektion auf alle Spalten des Datensatzes durchgeführt wird. Das kann unter Umständen den Datenbankserver unnötig belasten.

Fazit

Bei kleinen Hilfstabellen, bis ca. 10 Spalten, sollte man diesen Zugriff ruhig benutzen. Letztendlich ließt die Datenbank Blockweise die Daten ein und stellt sie dem Anwender zur Verfügung. Bei größeren Tabellen > 20 Spalten sollte man besser auf die klassische Art der Cursor-Programmierung zurückgreifen.

Allgemein

Ab der Oracle Datenbank Version 9.2 ist das INSERT-Statement um eine weitere funktionalität Erweitert worden. Es ist nun möglich, an eine Insert-Anweisung, statt einzelner Felder, einen kompletten Record zu übergeben. Dieser Record muss dabei die gleiche Struktur wie die entsprechende Tabelle widerspiegeln. Jedoch dürfen dabei einzelne Felder leer bleiben.

Der Vorteil dieser erweiterten funktionalität liegt vor allem daran, wenn man ein INSERT-Statement in eine Prozedur/Funktion einbettet und einen Datensatz als Parameter übergibt. Dadurch kann die Tabelle ohne Probleme erweitert/geändert werden ohne das der Parameter angepasst werden muss. D.h die Signatur der Prozedur/Funktion bleibt unverändert.

Source Code

Prozedur zum einfügen eines Datensatzes via ROWTYPE.

PROCEDURE do_insert(pi_rec hr.employees%ROWTYPE) IS 
BEGIN 
   INSERT INTO hr.employees VALUES pi_rec; 
   COMMIT; 
END do_insert;

Prozedur zum initialisieren der Felder.

PROCEDURE initialisierung IS 
   l_rec hr.employees%ROWTYPE; 
BEGIN 
   -- Der Inhalt des Feldes "employee_id" wird durch ein INSERT-Trigger gesetzt. 
   -- Die Inhalte der Felder "email", "phone_number" und "commission_pct" bleiben leer. 
   l_rec.first_name := 'Max'; 
   l_rec.last_name := 'Mustermann'; 
   l_rec.hire_date := SYSDATE; 
   l_rec.job_id := 'IT-PROG'; 
   l_rec.salary := 4800; 
   l_rec.manager_it := 103; 
   l_rec.department_id := 60;  
 
   do_insert(l_rec); 
END initialisierung;