Ergebnis einer StoredProc innerhalb anderer StoredProc "zwischenparken"

[Codehunter]

Hallo!

Ich habe folgenden StoredProc-Body:

Code:

SELECT * FROM A WHERE NOT A.FELD1 IN (SELECT DISTINCT ´ID´ FROM AndereProzedur(IrgendeinParameter));

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:

Code:

PARKPLATZ = (SELECT DISTINCT ´ID´ FROM AndereProzedur(IrgendeinParameter));
SELECT * FROM A WHERE NOT A.FELD1 IN PARKPLATZ;

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?

Grüße
Cody

[jobo]

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.

[mkinzler]

Du könntest den Wert in einer Kontextvariable zwischenspeichern

[jobo]

cool, wusste nicht das Firebird das kann.

[Codehunter]

Zitat:

Zitat von mkinzler (Beitrag 1421392)

Du könntest den Wert in einer Kontextvariable zwischenspeichern

Kannst du mal ein kurzes Beispiel geben? Geht das auch mit einer Ergebnismengen-RecordCount > 1?

[dataspider]

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

[mkinzler]

In der ursprünglichen Frage ging es um einen Wert:

SQL-Code:

select rdb$set_context('USER_SESSION' //oder USER_TRANSACTION, '<Name der Variable>', <Wert>) from rdb$database;

Mehrere Werte/Datensätze als Temp-Table

[jobo]

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..

[mkinzler]

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:

...
SELECT DISTINCT ´ID´ FROM AndereProzedur(IrgendeinParameter) into :ID;
 
SELECT * FROM A WHERE A.FELD1 <> :ID;
...

Oder mal Testen, wie gut optimiert wird

[dataspider]

Ich habe es mal mit derived table getestet.
Es sollte so:

SQL-Code:

select a.* from tabelle a
join (select distinct 'id' from andereprozedur(irgendeinparameter)) b on b.id = a.feld1
where p2.id is null

gehen.


Laut Leistungsananlyse von IBExpert nur jeweils 1 Durchlauf (mit meinen Testtabellen...

Frank

[Codehunter]

Zitat:

Zitat von dataspider (Beitrag 1421433)

SQL-Code:

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...

Interessante Idee. Auf einen Join wäre ich in dem Zusammenhang nicht gekommen. Ich vermute mal "p2.id" war hier ein Irrtum und "b.id" gemeint?

[dataspider]

Zitat:

Zitat von Codehunter (Beitrag 1421601)

Zitat:

Zitat von dataspider (Beitrag 1421433)

SQL-Code:

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...

Interessante Idee. Auf einen Join wäre ich in dem Zusammenhang nicht gekommen. Ich vermute mal "p2.id" war hier ein Irrtum und "b.id" gemeint?

Richtig

War ja auch schon spät...

Frank

[Codehunter]

Zitat:

Zitat von dataspider (Beitrag 1421433)

SQL-Code:

select a.* from tabelle a
join (select distinct 'id' from andereprozedur(irgendeinparameter)) b on b.id = a.feld1
where p2.id is null

Funktioniert leider nicht so wie gedacht. Denn dann würden nur diejenigen Datensätze zurückgegeben, wo a.feld1 = NULL ist. Entpricht also funktional nicht

Zitat:

Zitat von Codehunter (Beitrag 1421387)

SQL-Code:

SELECT * FROM A WHERE NOT A.FELD1 IN (SELECT DISTINCT ´ID´ FROM AndereProzedur(IrgendeinParameter));

Man beachte das NOT:

SQL-Code:

... WHERE **NOT** A.FELD1 IN (SELECT DISTINCT ...

Ohne das ginge das mit einem Join aber so fällt mir da spontan keine Lösung ein.

[jobo]

Aber da fehlt doch dann nur das "left" vorm "join"

noch mal sorry, kleines Durcheinander

[dataspider]

Zitat:

Zitat von Codehunter (Beitrag 1421612)

Zitat:

Zitat von dataspider (Beitrag 1421433)

SQL-Code:

select a.* from tabelle a
join (select distinct 'id' from andereprozedur(irgendeinparameter)) b on b.id = a.feld1
where p2.id is null

Funktioniert leider nicht so wie gedacht. Denn dann würden nur diejenigen Datensätze zurückgegeben, wo a.feld1 = NULL ist. Entpricht also funktional nicht

Zitat:

Zitat von Codehunter (Beitrag 1421387)

SQL-Code:

SELECT * FROM A WHERE NOT A.FELD1 IN (SELECT DISTINCT ´ID´ FROM AndereProzedur(IrgendeinParameter));

Man beachte das NOT:

SQL-Code:

... WHERE **NOT** A.FELD1 IN (SELECT DISTINCT ...

Ohne das ginge das mit einem Join aber so fällt mir da spontan keine Lösung ein.

Sorry, ich habe das gestern tatsächlich ohne dem NOT getestet.
Es geht zwar mit left join, aber die Anzahl der Reads hier deutlich größer.

Ich fürchte, bei NOT IN ... wird wohl eine zusätzliche Tabelle die besten Ergebnisse bringen.

Frank

[jobo]

Ein gelockertes Join Kriterium muss ja meist mehr Read produzieren. Find ich erstmal kein k.o. Kriterium. Und dabei kommt es ja dann auf die Mengengerüste beider Seiten an. Gibt es viele auszuschließende Datensätze oder andersrum ..
Ob das codehunter taugt, kann er wohl nur selbst testen.

[Codehunter]

Zitat:

Zitat von jobo (Beitrag 1421613)

Aber da fehlt doch dann nur das "left" vorm "join"

noch mal sorry, kleines Durcheinander

Hatte ich auch schon probiert, kommt letztlich aber das Gegenteil von dem heraus was rauskommen soll: Alle Datensätze aus Tabelle a wo der Wert in a.feld1 nicht in der Ergebnismenge von AndereProzedur() vorkommt. Bei einem Join (mit oder ohne Left) kommen aber genau die Datensätze, die nicht kommen sollen.

EDIT: Ich hänge heute irgendwie hinterher. Ihr wart immer schneller mit antworten :-) Ich hab halt auch das Gefühl, Firebird ist in manchen Dingen anderen Datenbanken wie MariaDB usw. unterlegen. Bei MariaDB kann ich mit

SQL-Code:

CREATE TEMPORARY TABLE ´PARKPLATZ´ FOR SELECT DISTINCT ...

einen solchen Parkplatz bauen wie im Eingangspost angedacht. Bei Firebird ist das deutlich mehr Arbeit.

[jobo]

Zitat:

Zitat von Codehunter (Beitrag 1421623)

Hatte ich auch schon probiert, kommt letztlich aber das Gegenteil von dem heraus was rauskommen soll: Alle Datensätze aus Tabelle a wo der Wert in a.feld1 nicht in der Ergebnismenge von AndereProzedur() vorkommt. Bei einem Join (mit oder ohne Left) kommen aber genau die Datensätze, die nicht kommen sollen.

Das dürfte aber keine Frage von mit oder ohne LEFT sein, sonder jedenfalls ein OUTER join und da dann eine Frage von LEFT oder RIGHT mit dem passenden IS NULL.

Ich bin gerade schon mit den Statements (Vorlage von Dir und Anpassung von dataspider) durcheinander gekommen. Das müsste bei Dir doch schnell erledigt sein, dass Du das Gegenteil von dem was du jetzt bekommst. (Hätte ich in der Grundschule bloß besser aufgepasst)

[jobo]

Zitat:

Zitat von Codehunter (Beitrag 1421623)

..Ihr wart immer schneller mit antworten :-)

Das müsstest Du doch kennen von diesem Forum!
Es fehlt nur noch ein winziges Stück und die Antworten kommen vor dem Eröffnungspost.

[Codehunter]

Zitat:

Zitat von jobo (Beitrag 1421626)

Zitat:

Zitat von Codehunter (Beitrag 1421623)

..Ihr wart immer schneller mit antworten :-)

Das müsstest Du doch kennen von diesem Forum!

In der Tat wundere ich mich öfters wie schnell einem hier geholfen wird. Manchmal verbunden mit dem schlechten Gewissen, mehr zu bekommen als man zurückgeben kann. Aber hilft einem ja auch schon das nachlesen in solchen Diskussionen, sodass es später trotzdem für andere hilfreich sein kann.

Zitat:

Zitat von jobo (Beitrag 1421626)

Es fehlt nur noch ein winziges Stück und die Antworten kommen vor dem Eröffnungspost.

Dazu müsste man wohl das Template von Blau auf Rot umstellen und einen Sound abspielen der "Ho Ho Ho" sagt ;-)

[dataspider]

Zitat:

Zitat von Codehunter (Beitrag 1421623)

Firebird ist in manchen ingen anderen Datenbanken wie MariaDB usw. unterlegen. Bei MariaDB kann ich mit

SQL-Code:

CREATE TEMPORARY TABLE ´PARKPLATZ´ FOR SELECT DISTINCT ...

einen solchen Parkplatz bauen wie im Eingangspost angedacht. Bei Firebird ist das deutlich mehr Arbeit.

Ich denke aber, der Aufwand ist überschaubar...

SQL-Code:

CREATE GLOBAL TEMPORARY TABLE TMP$ID (
    ID PK NOT NULL) ON COMMIT PRESERVE ROWS;
ALTER TABLE TMP$ID
ADD CONSTRAINT PK_TMP$ID
PRIMARY KEY (ID);

In der SP dann:

SQL-Code:

delete from tmp$id; -- vorsichtshalber
insert into tmp$id select distinct 'id' from andereprozedur(irgendeinparameter);
for select * from a where not a.feld1 in (select id from tmp$id) into....
do
begin
end;

Das bringt aber nur viel, wenn die andereprozedur tatsächlich langsam ist.
Um das richtig abzuschätzen, müsste man wisse, was andereprozedur macht.
Wäre der Select in andereprozedur ein indexierter mit 10 Reads bei 10 Zeilen Rückgabe, dann kannst du alles lassen wie es ist.

Frank