ORDER in Unterselect sehr langsam

[Gruber_Hans_12345]

@webcss: Das würde nur den größten AuftragID leifern und nicht den AuftragID der in dem datensatz mit der größten BUCHUNG steht ....


ABER :
Die letzte Stored Procedure läuft nun sehr gut

Habs nun "auf gut Glück" ins Programm selbst eingebaut

und brauch nun statt den 3 sekunden keine 1.5 sekunden mehr sondern mit der neuen nur mehr 60 ms

perfekt danke an alle

[hoika]

Hallo,

das ist doch schön ;)

*Rechnung schreib*


Heiko

[Delphianer]

Hallo Hans,

gratuliere zur Lösung. Es würde mich aber doch interessieren, wie schnell mein SQL ist. Postest Du dazu mal noch das Ergebnis?

Gruß,

Lutz

[Gruber_Hans_12345]

Ja gerne, also die "Sieger" Lösung bracuht für die Abfrage 60ms
Deine braucht 2.171 sekunden, allerdings liefert es auch falsche Auftragsdaten als ergebnis ....

[webcss]

Zitat:

Zitat von Gruber_Hans_12345

@webcss: Das würde nur den größten AuftragID leifern und nicht den AuftragID der in dem datensatz mit der größten BUCHUNG steht ....

Also ich hab das probiert mit meinen Daten in ähnlicher Konstellation, und es liefert mir die passende auftragID zum passenden Datum für die jeweilige Person...

[Delphianer]

Ich bin davon ausgegangen, dass Buchung unique ist, das war wohl falsch.

Den falschen SQL will ich aber nicht auf mir sitzen lassen. Wenn ich nicht wieder von den falschen Voraussetzungen ausgehe, sollte der das richtige Ergebnis liefern:

SQL-Code:

SELECT P.ID, TEMP.BUCHUNG, TB.AUFTRAGID FROM PERSONAL P
JOIN (SELECT PERSONALID, MAX(BUCHUNG) BUCHUNG FROM TERMINAL_BUCHUNGEN GROUP BY PERSONALID) TEMP on TEMP.PERSONALID=P.ID
JOIN TERMINAL_BUCHUNGEN TB ON TEMP.BUCHUNG = TB.BUCHUNG and TEMP.PERSONALID = TB.PERSONALID

Eigentlich kann ich mir nicht vorstellen, dass dieser SQL so grottenschlecht ist. Mit den passenden Indizes sollte der wenigstens in die Nähe der Siegerlöscung kommen.

Lutz

[webcss]

Zitat:

Zitat von webcss

Zitat:

Zitat von Gruber_Hans_12345

@webcss: Das würde nur den größten AuftragID leifern und nicht den AuftragID der in dem datensatz mit der größten BUCHUNG steht ....

Also ich hab das probiert mit meinen Daten in ähnlicher Konstellation, und es liefert mir die passende auftragID zum passenden Datum für die jeweilige Person...

Davon abgesehen liefert die SP auch die Datensätze wo AuftragID z.B. NULL ist.
Die Ausführungsgeschwindigkeit ist gleich.

Ich habe auch geprüft, ob evtl. unterschiedliche Daten zurückgegeben werden: Fehlanzeige, die Rückgabewerte miener Abfrage und die der SP sind identisch.

[Gruber_Hans_12345]

ok, die von delphianer, läuft nun auch mit 200ms (wobei die 200ms und 60ms wahrscheinlich ca gleich sind .... )
Die Daten sind auch richtig, es werden mit dem INNER JOIN halt die NULL ausgeblendet.

Die Daten von webcss, sind aber definitiv falsch, da hier ja nur der MAX(AUFTRAGID) gelifert wird, und das ist ja nicht gewünscht

Übrigens ein sehr interessanter Ansatz das bei delphianer - Danke vielmals dafür, so hatteich das nich nei irgendwo verwendet ...

[webcss]

Zitat:

Zitat von Gruber_Hans_12345

Die Daten von webcss, sind aber definitiv falsch, da hier ja nur der MAX(AUFTRAGID) gelifert wird, und das ist ja nicht gewünscht

Das basiert allerdings nur auf einer Theorie, oder hast Du es wenigstens mal ausprobiert? Ich habe es ausprobiert.

Die Aufgabenstellung: Finde die PersonalID und AuftragID zur jeweils letzten Buchung.
Versuchsaufbau:

Eine VIEW mit meiner Lösung, eine SP ala hoika.

Dann folgende Abfrage:

SQL-Code:

select spb.PersonalID, vwb.PersonalID, spb.Buchung, vwb.Buchung, spb.AuftragID, vwb.AuftragID from Sp_Buchung spb
inner join vw_Buchung vwb on vwb.AuftragID=spb.AuftragID
where spb.AuftragID is not null
and (vwb.AuftragID<>spb.AuftragID or vwb.Buchung <> spb.Buchung or vwb.PersonalID<>spb.PersonalID)

Sieh Dir das Ergebnis an (NULL) und sag mir was daran falsch ist...