Office: (Office 2013) Abfrage schnellste Rennrunden

Natürlich. Es kann aber sein, die SQL-Anweisung wird durch die steigende Länge unübersichtlich. Du behältst das im Griff? Ansonsten dürfen SQL-Anweisungen in Jet bis etwa 64.000 Zeichen lang werden - da ist noch etwas Spielraum vorhanden.

Nur pro Session oder oder wieder auch pro Fahrer, ... usw.?
Aufgaben sollten eindeutig formuliert sein.

Da wie bereits oben angemerkt die Berechnungen zu Rängen und Durchschnitten jetintern ziemlich aufwändig sind, wäre es sinnvoll, diese Filterung gleich an der Basis vorzunehmen, also jeweils die Tabelle Import_Lap_Report zu ersetzen durch eine Abfrage, wo die gewünschten Einschränkungen erfolgen.

 

Hi Eberhard,

pro Session sollten für jeden Fahrer seine schnellsten Runden dargestellt werden, die höchstens 5% langsamer als die schnellste Runde dieses Fahrers sind. Falls diese Bedingung auf mehr als 10 Runden zutrifft, soll die Auswahl auf maximal 10 Runden beschränkt werden.
Es wäre super, wenn Du mir einen Ansatz für die Abfrage der 5% geben könntest?

 

Ansätze:
Code:

Code:

Hier wurde nur jeweils ein Gruppierungsmerkmal eingesetzt, Du hast ja mehrere. Der ausgewählte Ansatz (ich würde zum zweiten tendieren, da Unterabfrage X nur einmal berechnet werden muss) wäre dann in die eingangs besprochene TOP-10-Lösung einzusetzen, und das dann in den Rest.
Siehe auch Grundlagen - SQL ist leicht (6) - Komplexe Abfragen schreiben und lesen

Nebenbei könnte man darüber nachdenken, die Filtersetzung inklusive Parametrisierung auf diese Basisebene zu verlagern (=> frühzeitiges Einschränken der Datenmenge senkt nachfolgenden Rechenaufwand).

Und wenn man "unten" die Top 10 ermittelt, kann man dann später auf die Rangberechnung und dortige Auswahl der TOP 10 verzichten. Sprich: Ehe man hier oder da einen Zusatz dazupackt, könnte man erst einmal über Abläufe nachdenken (Ausgangssituation => wahres Ziel).

 

Danke für die Ansätze.

Ich habe mich am zweiten Ansatz versucht und bin zu folgendem Code gekommen:

Code:

Mir erschließt sich der Parameter "d" nicht. Was soll ich für ihn einsetzen und was genau bewirkt die "ON T.d=X.d"-Anweisung?
Ist der Rest des Codes halbwegs in die richtige Richtung? Ich merke grade leider, dass ich etwas verloren bin *frown.gif*

 

d steht z.B. für Driver, w für Wert (Laptime). Ich habe nur schnell eine Kurztabelle erstellt und verwendet, um Ansätze zu testen, stark abgekoppelt von Deiner Situation und Deinen Bezeichnungen, also auch nicht 1:1 übernehmbar.

Oh ja, wenn man etwas live in eine SQL-Anweisung einträgt, die etwas länger und komplexer ist, muss man sie vorher verstehen, richtig verstehen. Da braucht man etwas Abstraktionsvermögen.

Versuche, schrittweise zu arbeiten: Speichere den Ansatz mit Deinen Bezeichnungen, dann auch mit Track und Session, als Abfrage ab. Dann kannst Du auch das Zwischenergebnis betrachten und Deiner Erwartung gegenüberstellen. Ersetze in der aufbauenden Abfrage Deine bisherige Tabelle durch diese Abfrage, was durch die Verwenung von Aliasen ja sehr übersichtlich ist. Aber dann auch in der Unterabfrage, damit die TOP10-Ermittlung die gleiche und richtige Basis hat.

 

Ich habe Deinen Rat befolgt und die Abfragen aufgeteilt. Zunächst die besten 5%-Runden (habe 2,5% genommen).

Code:

Anschließend davon die 10 besten Runden.

Code:

Eine kleine Frage zum Verständis: Im zweiten "FROM" beziehe ich mich ja wieder auf die Ausgangstabelle. Das wird immer so gemacht, richtig? Und nach dem "WHERE" stelle ich sicher, dass nur die Werte, die auch in Q_BesteRundenzeitenProzent1 vorkommen, genommen werden, oder? Da ich in der ersten Abfrage schon die Bedingung gesetzt habe, dass die Rundenzeit>0 sein muss, muss diese jetzt nicht nochmal aufgeführt werden, richtig?

Nun möchte ich den Rang hinzufügen:

Code:

Hier hänge ich grade fest. Die Werte werden zwar hochgezählt, aber ab und zu springen sie plötzlich von z.B. 6 auf 14, obwohl sie ja eigentlich höchsten 10 sein sollten. Der Code greift ja beim Hochzählen auf die Ausgangstabelle zu, also war meine Vermutung, dass ich die beiden Tabellennamen tauschen muss. Dann kommt aber die Meldung, dass sich die Felder auf mehr als eine der Tabellen beziehen können.
Danke für deine Geduld.

 

Das ist in diesem Anwendungsfall grundsätzlich falsch, könnte aber zufällig keine Abweichungen (Fehler) erzeugen. Sicherheitshalber müssten Hauptabfrage und Unterabfrage auf die gleiche "Tabelle" aufbauen, Abweichungen müssen sorgfältigst kalkuliert sein.

In der Unterabfrage fehlt die Sortierung, so dass die TOP10-Auswahl zufällig erfolgt. Vielleicht ist das in den Ergebnissen nicht erkennbar, weil es pro Gruppe nur

 

Ich habe den Code nochmals angepasst und das Jahr als weiteres Kriterium eingefügt.
Code:

Code:

2.Code: Obwohl ich in der WHERE-Klausel die Kriterien angegeben habe, werden mir bei der Abfrage nur 10 Runden ausgegeben? Ich habe mit bei der TOP10-Abfrage an Deinem Code orientiert. Wenn ich X.ID und T.ID gegen X.Laptime und T.Laptime ersetze, erhalte ich die selben Werte. Sollte ich überhaupt mit der ID bei der TOP10-Abfrage arbeiten?

 

Durchaus, und wenn die ID auch eindeutig ist, ist das anwendungssicherer als z.B. Laptime, da bei Zeiten auch gleiche Zeiten auftreten können.

Aber das X.ID=T.ID in der ersten Abfrage sieht sehr krumm aus. Überprüfe das noch einmal.

 

Ich denke, dass das Code:

in die WHERE-Klausel nicht reingeschrieben sollte, weil es ja ein eindeutiger Wert ist und damit die Abfrage jeden Datensatz ausgibt. Auch die Startnummer habe ich herausgenommen, weil dies ja kein zwingendes Kriterium ist, da ich von jedem Fahrer die schnellsten Runden haben möchte, egal welche Startnummer. Also bin ich zu folgendem Code gekommen:
Code:

Für die TOP10-Abfrage habe ich mich an Deinem Code orientiert:
Code:

Angepasst auf meine Anwendung:
Code:

Aber jetzt werden nur 10 Runden insgesamt angezeigt, obwohl der Code mMn identisch ist. Wo liegt der Denkfehler?

 

Ein Fehler springt mir jetzt nicht ins Auge.
Manchmal sind auch die Daten der Fehler, sprich mit den verwendeten Daten ist bei gegebener Anweisung kein anderes Ergebnis möglich.

Insgesamt sinkt aber auch mein Abstraktionsvermögen, weil ich immer weniger verstehe, was Du da probierst und ausführst.

Eine Demo mit belastbaren Daten wäre hilfreich, um auf ein ebenbürtiges Gesprächsniveau zu kommen.

 

Hier eine Beispieldatei mit anderen Daten. Dort tritt der gleiche Fehler auf.

 

Ich finde keinen, trotz mehrmaliger Versuche.

Nach der DB ist es so, dass in der zweiten Abfrage die 10 schnellsten Zeiten absolut ermittelt werden. Die Gruppierung, die in der Unterabfrage über die WHERE-Kriterien vorgenommen wird, wird ignoriert.

Wenn Du den Inhalt der ersten Abfrage über eine Tabellenerstellungsabfrage in eine (neue) Tabelle schreibst und dann diese Tabelle statt der Abfrage als Datenbasis für die zweite Abfrage nimmst, tritt dann wieder das erwartete Verhalten ein.

Wie gesagt, das Verhalten ist mir unerklärlich und mit Syntax (aus meiner Erfahrung) nicht zu erklären. Vermutlich kann der Jet-Parser die beiden Abfragen in dieser Kombination nicht korrekt zusammenbringen und erzeugt ein falsches Ergebnis.
Das habe ich bisher noch nicht gesehen: Keine Fehlermeldung, sondern falsches Ergebnis.

 

Hi Eberhard,

das ist sehr merkwürdig. Und ich habe mich die ganze Zeit gefragt, warum der Code nicht funktioniert.
Ich war ja mit folgendem Code schon kurz vorm Ziel. Hier fehlt nur noch die Filterung auf die Runden, die höchstens 2,5% langsamer sind und anschließend die TOP10 davon. Kann dieser Code noch darauf angepasst werden?

Code:

 

Fällt Dir etwas auf, wenn Du das berechnete Feld LaptimeRank betrachtest?
Ein TOP10 entspricht einem LaptimeRank 0
) AS Y
WHERE
Y.Year = S.Year
AND
Y.Track = S.Track
AND
Y.Session = S.Session
AND
Y.CarNumber = S.CarNumber
AND
Y.Driver = S.Driver
AND
Y.LapTimeRank 0
AND
X.Laptime < T.Laptime
)
+ 1 AS LapTimeRank
FROM
Import_Lap_Report AS T
WHERE
T.Laptime > 0
) AS S;[/quote] Violette Markierungen: Problematische Bezeichnungen, müssen geklammert werden.

Zu 3)
Code: