Verarbeitung parametrisierter Befehle
Wenn Sie mit einem großen untergeordneten Recordset (insbesondere im Vergleich zur Größe des übergeordneten Recordsets) arbeiten, aber nur auf wenige untergeordnete Kapitel zugreifen müssen, kann es effizienter sein, einen parametrisierten Befehl zu verwenden.
Ein nicht parametrisierter Befehl ruft sowohl das gesamte übergeordnete als auch das untergeordnete Recordset ab, fügt eine Kapitelspalte an das übergeordnete Recordset an und weist dann einen Verweis auf das zugehörige untergeordnete Kapitel für jede übergeordnete Zeile zu.
Ein parametrisierter Befehl ruft das gesamte übergeordnete Recordset ab, ruft das Kapitel-Recordset jedoch nur ab, wenn auf die Kapitelspalte zugegriffen wird. Dieser Unterschied bei der Abrufstrategie kann erhebliche Leistungsvorteile bieten.
Sie können z. B. Folgendes angeben:
SHAPE {SELECT * FROM customer}
APPEND ({SELECT * FROM orders WHERE cust_id = ?}
RELATE cust_id TO PARAMETER 0)
Die übergeordneten und untergeordneten Tabellen weisen einen gemeinsamen Spaltennamen auf, cust_id. Der untergeordnete Befehl enthält einen Platzhalter „?“, auf den sich die RELATION-Klausel bezieht (d. h. „... PARAMETER 0“).
Hinweis
Die PARAMETER-Klausel betrifft ausschließlich die Syntax des SHAPE-Befehls. Sie ist weder dem ADO-Parameter-Objekt (ActiveX Data Objects) noch der Parameters-Sammlung zugeordnet.
Wenn der parametrisierte SHAPE-Befehl ausgeführt wird, geschieht Folgendes:
Der übergeordnete Befehl wird ausgeführt und gibt ein übergeordnetes Recordset aus der Tabelle „Customers“ zurück.
Eine Kapitelspalte wird an das übergeordnete Recordset angefügt.
Wenn auf die Kapitelspalte einer übergeordneten Zeile zugegriffen wird, wird der untergeordnete Befehl mit dem Wert von „customer.cust_id“ als Parameterwert ausgeführt.
Alle Zeilen im Datenanbieter-Rowset, das in Schritt 3 erstellt wird, werden verwendet, um das untergeordnete Recordset aufzufüllen. In diesem Beispiel sind dies alle Zeilen in der Tabelle „Orders“, in denen der Wert von „cust_id“ dem Wert von „customer.cust_id“ entspricht. Standardmäßig werden die untergeordneten Recordsets auf dem Client zwischengespeichert, bis alle Verweise auf das übergeordnete Recordset freigegeben werden. Wenn Sie dieses Verhalten ändern möchten, legen Sie die dynamische Eigenschaft zum Zwischenspeichern untergeordneter Zeilen des Recordsets auf False fest.
Ein Verweis auf die abgerufenen untergeordneten Zeilen (also das Kapitel des untergeordneten Recordsets) wird in der Kapitelspalte der aktuellen Zeile des übergeordneten Recordsets platziert.
Die Schritte 3 bis 5 werden wiederholt, wenn auf die Kapitelspalte einer anderen Zeile zugegriffen wird.
Die dynamische Eigenschaft zum Zwischenspeichern untergeordneter Zeilen ist standardmäßig auf True festgelegt. Das Verhalten beim Zwischenspeichern variiert je nach den Parameterwerten der Abfrage. In einer Abfrage mit einem einzelnen Parameter wird das untergeordnete Recordset für einen bestimmten Parameterwert zwischen Anforderungen für ein untergeordnetes Element mit diesem Wert zwischengespeichert. Dies veranschaulicht der folgende Code:
SCmd = "SHAPE {select * from customer} " & _
"APPEND({select * from orders where cust_id = ?} " & _
"RELATE cust_id TO PARAMETER 0) AS chpCustOrder"
Rst1.Open sCmd, Cnn1
Set RstChild = Rst1("chpCustOrder").Value
Rst1.MoveNext ' Next cust_id passed to Param 0, & new rs fetched
' into RstChild.
Rst1.MovePrevious ' RstChild now holds cached rs, saving round trip.
In einer Abfrage mit zwei oder mehr Parametern wird nur dann ein zwischengespeichertes untergeordnetes Element verwendet, wenn alle Parameterwerte mit den zwischengespeicherten Werten übereinstimmen.
Parametrisierte Befehle und komplexe Beziehungen zwischen über- untergeordneten Elementen
Zusätzlich zur Verwendung parametrisierter Befehle zum Verbessern der Leistung einer Gleichheitsjoin-Hierarchie können parametrisierte Befehle verwendet werden, um komplexere Beziehungen zwischen über- untergeordneten Elementen zu unterstützen. Nehmen wir als Beispiel eine Little League-Datenbank mit zwei Tabellen: eine besteht aus den Teams (team_id, team_name) und die andere aus den Spielen (date, home_team, visiting_team).
Bei einer nicht parametrisierten Hierarchie ist es nicht möglich, die Tabellen mit den Teams und Spielen so zu verknüpfen, dass das untergeordnete Recordset für jedes Team den vollständigen Spielplan enthält. Sie können Kapitel erstellen, die den Heimspielplan oder den Auswärtsspielplan enthalten, aber nicht beides. Dies liegt daran, dass die RELATION-Klausel Sie auf Beziehungen zwischen über- und untergeordneten Elementen in der Form (pc1=cc1) AND (pc2=pc2) beschränkt. Wenn Ihr Befehl „RELATE team_id TO home_team, team_id TO visiting_team“ enthält, erhalten Sie daher nur Spiele, bei denen ein Team selbst gespielt hat. Was Sie wollen, ist „(team_id=home_team) OR (team_id=visiting_team)“, der Shape-Anbieter unterstützt die OR-Klausel jedoch nicht.
Um das gewünschte Ergebnis zu erhalten, können Sie einen parametrisierten Befehl verwenden. Zum Beispiel:
SHAPE {SELECT * FROM teams}
APPEND ({SELECT * FROM games WHERE home_team = ? OR visiting_team = ?}
RELATE team_id TO PARAMETER 0,
team_id TO PARAMETER 1)
In diesem Beispiel wird die größere Flexibilität der SQL-WHERE-Klausel genutzt, um das gewünschte Ergebnis zu erhalten.
Hinweis
Bei der Verwendung von WHERE-Klauseln können Parameter die SQL-Datentypen für „text“, „ntext“ und „image“ nicht verwenden, da andernfalls ein Fehler mit der folgenden Beschreibung auftritt: Invalid operator for data type
Weitere Informationen
Data Shaping Example (Beispiele der Datenstrukturierung)
Formale Grammatik für Formen
Shape-Befehle im Allgemeinen