aktuellsten Record (anhand Datum/Uhrzeit) ermitteln

[hoika]

Hallo #,

folgendes Tabelle habe ich (Dialect 1)

Id Integer // prim key
EventDate Date
EventTime Date
EventId Integer

Ich möchte jetzt für eine bestimmte EventId den letzten Eintrag haben.
Id geht aus bestimmten Gründen nicht.

Ich muss EventDate/EventTime benutzen.
Bisher mache ich das immer so (IB6.0 geschädigt)

Select EventDate,EventTime,EventId
Order By EventDate Desc, EventTime Desc

Dann hole ich mir den ersten Eintrag und der ist ja der aktuellste

Unter FB1.5 geht auch das

Select First 1 EventDate,EventTime,EventId
Order By EventDate Desc, EventTime Desc

Jetzt die Frage.
Der Queryplan ist der gleiche, die Abfragezeit auch (ok, ok, wenige Records)
Aber: Wie genau wird das First 1 von FB optimiert?

Ist die interne Abfrage schon optimiert ?
Ist das Resultset auf dem Server schon kleiner (1 Record),
oder macht der erst beim Fetch nach dem 1. Datensatz Schluss ?


Die Release Notes sagen nicht viel darüber aus ?

Hat jemand praktische Erfahrungen ?



Danke
Heiko

[shmia]

Ohne Index auf EventDate und EventTime ist der Server zu einem Full Table Scan gezwungen.
D.H. er muss auf jeden Fall die ganze Tabelle durchrattern und sich EventDate und EventTime sortiert merken.
Erst wenn er die ganze Liste aufgebaut hat, werden die Daten ausgegeben, wobei die Ausgabe nach dem 1. Datensatz beendet ist.
Die Liste enthält dabei nicht alle Daten die ausgegeben werden sollen, sondern nur die Reihenfolge der Datensätze.
Also: ORDER BY bedeutet nicht, das die ganzen Daten sortiert im Speicher sein müssen. (Stichwort: indirektes Sortieren)

Sollte auf EventDate und EventTime ein Index liegen, kann der Server diesem Index in der richtigen Richtung folgen und ist damit bei vielen Datensätzen deutlich schneller.
Der Performancegewinn stellt sich aber erst ab einer bestimmten Datensatzanzahl (50..1000) ein.

[shmia]

Ohne Index auf EventDate und EventTime ist der Server zu einem Full Table Scan gezwungen.
D.H. er muss auf jeden Fall die ganze Tabelle durchrattern und sich EventDate und EventTime sortiert merken.
Erst wenn er die ganze Liste aufgebaut hat, werden die Daten ausgegeben, wobei die Ausgabe nach dem 1. Datensatz beendet ist.
Die Liste enthält dabei nicht alle Daten die ausgegeben werden sollen, sondern nur die Reihenfolge der Datensätze.
Also: ORDER BY bedeutet nicht, das die ganzen Daten sortiert im Speicher sein müssen. (Stichwort: indirektes Sortieren)

Sollte auf EventDate und EventTime ein Index liegen, kann der Server diesem Index in der richtigen Richtung folgen und ist damit bei vielen Datensätzen deutlich schneller.
Der Performancegewinn stellt sich aber erst ab einer bestimmten Datensatzanzahl (50..1000) ein.

[hoika]

Hallo,

die Frage war aber nicht der Index, sondern das First 1.
Wird das von FB gesondert schon beim Execute benutzt,
oder baut er das Result-Set komplett auf und gibt dann
nur das 1. Ergebnis zurück ?



Heiko
PS: Dass der Index desc sein muss, ist auch klar.

[shmia]

Zitat:

Zitat von hoika

die Frage war aber nicht der Index, sondern das First 1.
Wird das von FB gesondert schon beim Execute benutzt,
oder baut er das Result-Set komplett auf und gibt dann
nur das 1. Ergebnis zurück ?

Zuerst kommt das Sortieren. Beim Indirekten Sortieren werden die eigentlichen Daten nicht im Speicher gehalten.
Es macht (im Prinzip) keinen Unterschied, ob die Tabelle 5 oder 100 Felder hat oder wieviele Felder im Resultset sein sollen.
Danach kommt die Ausgabe des Resultsets. Die SQL Engine erkennt schon nach der Ausgabe des 1. Records, dass sie fertig ist und hört auf.
=> also baut er das Result-Set nicht komplett auf

Zitat:

Zitat von hoika

PS: Dass der Index desc sein muss, ist auch klar.

Wenn FB "schlau" ist und der Index aufsteigend ist, die Sortierung aber absteigend sein soll, dann wird FB
den Indexbaum einfach "rückwärts" durchlaufen.
Nur wenn EventDate aufsteigend, aber nach EventTime absteigend sortiert werden soll, aber ein gemeinsamer Index auf den Feldern liegt, kann die SQL Engine den Index nicht verwenden.

[hoika]

Hallo,

Nö,

da muss ich mal sagen, stimmt nicht ....

Ein Asc Index wird von FB NIE für Desc-Suche benutzt.
Rückwärts suchen kann FB nicht.
Das liegt daran, dass die Index-Daten selbst komprimiert sind,
und zwar so, dass nur die richtige Suche (asc/desc) verwendet werden kann.

Deshalb sagt man ja immer auch, für Desc Search immer einen Desc-Index anlegen.

Würde ich allerdings EventDate Asc / EventTime Desc suchen,
müsste ein zusammenhängender Index mindestens EventDate Asc haben,
ein EventDate Asc / EventTime Desc würde auch gehen
das EventDate würde per Index würde, dass EventTime "zu Fuß" gesucht.


Heiko