![]() |
Datenbank: Firebird • Version: 2.5.8 • Zugriff über: FIBPlus
Ergebnis einer StoredProc innerhalb anderer StoredProc "zwischenparken"
Hallo!
Ich habe folgenden StoredProc-Body:
Code:
Ich frage mich jetzt, wie Firebird den Ablauf realisiert. Wird für jede einzelne Zeile in Tabelle A das SELECT DISTINCT... ausgeführt? Oder wird zuerst einmalig das Ergebnis aus AndereProzedur() geholt und dann immer gegen dieses Ergebnis geprüft? Hintergrund der Frage ist die Laufzeitoptimierung. AndereProzedur() ist nicht gerade von der schnellen Sorte, würde hier aber IMMER das selbe Ergebnis liefern. Falls Firebird also dieses Ergebnis für jede Zeile neu aus AndereProzedur() holen würde, dann müsste ich deren Ergebnis "zwischenparken". Also ungefähr so:
SELECT * FROM A WHERE NOT A.FELD1 IN (SELECT DISTINCT ´ID´ FROM AndereProzedur(IrgendeinParameter));
Code:
Ich hoffe ihr versteht worauf ich hinaus will. Also eigentlich zwei Fragen: Erstens wie arbeitet Firebird diesen verschachtelten Query ab und zweitens, wie kann ich ein Unterergebnis in einer Variablen zwischenparken?
PARKPLATZ = (SELECT DISTINCT ´ID´ FROM AndereProzedur(IrgendeinParameter));
SELECT * FROM A WHERE NOT A.FELD1 IN PARKPLATZ; Grüße Cody |
AW: Ergebnis einer StoredProc innerhalb anderer StoredProc "zwischenparken"
Da Du einen Parameter da drin hast und die Proc sowieso auf sich potentiell ändernden Daten arbeitet, müsste es dauernd neu berechnet werden.
Ich weiß nicht, ob FB einen Mechnismus hat, mit dem es eine Funktionsergebnis als immutable deklarieren kann. Ansonsten ist halt Handarbeit angesagt, mit Zwischentabelle und benutzerspezifischen Ergebniseinträgen. |
AW: Ergebnis einer StoredProc innerhalb anderer StoredProc "zwischenparken"
Du könntest den Wert in einer Kontextvariable zwischenspeichern
|
AW: Ergebnis einer StoredProc innerhalb anderer StoredProc "zwischenparken"
cool, wusste nicht das Firebird das kann.
|
AW: Ergebnis einer StoredProc innerhalb anderer StoredProc "zwischenparken"
Zitat:
|
AW: Ergebnis einer StoredProc innerhalb anderer StoredProc "zwischenparken"
Ich glaube nicht, dass das geht.
Du kannst einen Wert speichern. Dazu kann man auch eine normale SP - Variable nehmen. Aber das Ergebnis eines Select' s mit mehreren Ergebniszeilen Zeilen ist IMHO nicht möglich. Man könnte für den Fall eine Temporäre Tabelle (z. B. "TMP$ID" mit FELD ID) anlegen mit den ID' s aus AndereProzedur füllen. Dann halt: SELECT * FROM A WHERE NOT A.FELD1 IN (SELECT ´ID´ FROM TMP$ID); Das wäre sicher erheblich schneller... Frank |
AW: Ergebnis einer StoredProc innerhalb anderer StoredProc "zwischenparken"
In der ursprünglichen Frage ging es um einen Wert:
SQL-Code:
Mehrere Werte/Datensätze als Temp-Table
select rdb$set_context('USER_SESSION' //oder USER_TRANSACTION, '<Name der Variable>', <Wert>) from rdb$database;
|
AW: Ergebnis einer StoredProc innerhalb anderer StoredProc "zwischenparken"
Geht denn Temptable in FB SP?
Aber es muss ja nicht temp sein, Hauptsache der Inhalt wird passend eingetragen (und gelöscht). Frage wäre auch, was insgesamt der Zweck des Statements ist. Vielleicht tut es ja schon ein View oder eine Kombi View mit Context Variable.. |
AW: Ergebnis einer StoredProc innerhalb anderer StoredProc "zwischenparken"
Wenn man Zugriff auf den Source der SP hat wäre der beste Weg das Ergebnis für ID in einer loaklen Variable zu Speichern.
SQL-Code:
Oder mal Testen, wie gut optimiert wird
...
SELECT DISTINCT ´ID´ FROM AndereProzedur(IrgendeinParameter) into :ID; SELECT * FROM A WHERE A.FELD1 <> :ID; ... |
AW: Ergebnis einer StoredProc innerhalb anderer StoredProc "zwischenparken"
Ich habe es mal mit derived table getestet.
Es sollte so:
SQL-Code:
gehen.
select a.* from tabelle a
join (select distinct 'id' from andereprozedur(irgendeinparameter)) b on b.id = a.feld1 where p2.id is null Laut Leistungsananlyse von IBExpert nur jeweils 1 Durchlauf (mit meinen Testtabellen... Frank |
Alle Zeitangaben in WEZ +1. Es ist jetzt 08:21 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz