MAX in SQL mit Datum Zeit und Suffix

[kitvb1]

Sie können mal so versuchen:

select Lagerort, Artikel, trim(char(Datum)) || trim(char(Zeit)) || trim(char(Suffix))
where Lagerort = 'LO' and Datum between 20080901 and 20080930
order by Lagerort, Artikel desc
fetch first row only

[Fuerchau]

@kitvb1
Tut mir Leid, aber das ist sowas von falsch:
Sortierung des Begriffes "trim(..." fehlt, da ja hier das letzte ermittelt werden soll und nicht der letzte Artikel.
Ausserdem werden durch char(Datum) und char(Zeit) Vornullen entfernt (siehe auch oben), was zur falschen Sortierung führt.
Mein Vorschlag war ja DIGITS zu nehmen und TRIM zu entfernen:

select Lagerort, Artikel, max(digits(Datum) || digits(Zeit) || char(Suffix))
where Lagerort = 'LO' and Datum between 20080901 and 20080930
Group by Lagerort, Artikel

[Pikachu]

Anderer Vorschlag:

SELECT   *                                  
FROM     DATTIMP                            
WHERE   (LAGERORT,ARTIKEL,DATUM,ZEIT) IN (  
SELECT   LAGERORT,ARTIKEL,DATUM,MAX(ZEIT)   
FROM     DATTIMP                            
WHERE   (LAGERORT,ARTIKEL,DATUM) IN (       
SELECT   LAGERORT,ARTIKEL,MAX(DATUM)        
FROM     DATTIMP                            
WHERE    LAGERORT='LO'                      
AND      DATUM BETWEEN 20080901 AND 20080930
GROUP BY LAGERORT,ARTIKEL)                  
GROUP BY LAGERORT,ARTIKEL,DATUM)            
ORDER BY LAGERORT,ARTIKEL,DATUM,ZEIT

[kitvb1]

@Fuerchau,

Tjcha, da haben Sie vollkommen recht, weiss ich auch nicht ich da gedacht habe. Senioren moment?

[Fuerchau]

Da fragt sich, wer denn hier der Senior ist .
Funktionierts denn jetzt endlich ?

[kitvb1]

Was ich als zweckpunkt gewollt habe, ist die möglichkeit besteht um es
ohne max(...)
mit nutzung von
order by... /desc
fetch first/last
auch schaffen kann.
Dazu wollte ich auch fragen, welche läuft schneller? Mit max(...) oder fetch first?

[Fuerchau]

Wenn entsprechende Zugriffswege vorhanden sind, ist fetch first schneller.
Das setzt aber auch einen DESC-Key voraus, denn ich weiß nicht, ob der Optimizer ggf. auch rückwärts optimiert.

Bei zusammengesetzten Feldern erübrigt sich ja eigentlich die Frage .

[B.Hauser]

Hey Kit,

Was ich als zweckpunkt gewollt habe, ist die möglichkeit besteht um es
ohne max(...)
mit nutzung von
order by... /desc
fetch first/last
auch schaffen kann.
Dazu wollte ich auch fragen, welche läuft schneller? Mit max(...) oder fetch first?

Werden die Abfragen mit den SQE ausgeführt und wird jeweils nur der Maximal-Wert selektiert, wird der gleiche Zugriffsplan verwendet, d.h. Zeitabweichungen hängen lediglich von der Auslastung auf der Maschine ab.

Die folgenden Abfragen werden original gleich ausgeführt. Es existiert ein Zugriffsweg nach FldX.

Select Max(Fldx)
From MyTable; 

Select FldX
from MyTable
Order By FldX Desc
Fetch First Row Only; 

Das setzt aber auch einen DESC-Key voraus, denn ich weiß nicht, ob der Optimizer ggf. auch rückwärts optimiert.

Die CQE braucht eine absteigend sortierten Zugriffspfad (in beiden Fällen!). SQE kann eine Zugriffsweg auch rückwärts verarbeiten.

Wird die Abfrage mit der CQE ohne entsprechenden Zugriffsweg verarbeitet, ist die Variante mit der Aggregat-Funktion (MAX) wesentlich schneller als die Variante mit dem Fetch! In der Fetch Variante wird eine temporäre Datei gebildet während bei der anderen Variante gruppiert werden kann.

Bei entsprechend sortiertem Zugriffsweg wird dieser bei der Fetch-Variante verwendet, während im anderen Fall weiterhin ein Table Scan mit Grouping verwendet wird.

Bei zusammengesetzten Feldern erübrigt sich ja eigentlich die Frage

Vor 6.1 ja, ab 6.1 können auch Indices über zusammengesetzte Felder oder durch skalare Funktionen veränderte Felder gebildet werden. Diese Indices können dann auch vom Optimizer verwendet werden.

Birgitta

[Pikachu]

Liefert FETCH FIRST nicht nur einen einzigen Datensatz je Abfrage zurück? Du brauchst doch aber mehrere Datensätze, für jeden Artikel je Lagerort einen?

[Fuerchau]

Ich glaub jetzt sind wir weit am Thema vorbei.
Fetch first löst natürlich nicht obiges ursprüngliches Problem.