Zitat von
Elvis:
Wenn du soviele Records hast, dann ist das allerallerallerletzte, was du jemals tun willst, das Zeug zu sortieren...
Der muss doch sonst ALLES ausführen und in ene temp table werfen bevor er dir auch nur den ersten Record geben könnte.
Du willst die Abfrage so bauen, dass er mit sowenig wie möglich Speicher durch die Daten "scrollen" kann.
Eine pipeline Funktion wie die dich in in dem einfachen Beispiel oben gab, sollte das möglich machen.
Ob du dieDaten dann in Ora lassen willst, oder durch eine externe App ziehen und speichern willst, musst du wissen.
ABER KEINE SORTIERUNG IN DER
DB!
Ja, die
DB muss alles sortieren, wenn nicht, muss Du aus der Applikation heraus Dir sonst den besten von 11 möglichen Treffern je Datensatz holen und das machst Du nicht schneller als die Datenbank.
Habe ähnlichen "Scheiß" schon mit deutlich größeren Datenmengen machen müssen und immer wieder feststellen dürfen, dass die Datenbank (vorausgesetzt Du hast einen vernünftigen Server dafür) das schneller kann als Du mit C++ oder sonstwas.
Wir haben früher auch mal 170 Mio. Sätze ohne Sortierung aus der Datenbank geholt, dass dann in C++ in 'ne Map gepackt und dort sortiert, um mit den Ergebnissen weiterzuarbeiten. Die Datenbank war da immer schneller.
Wesentlich ist, bei der
SQL-Abfrage von vorneherein die Ergebnismenge so gering wie möglich zu halten, auch wenn die
SQL's durch Schachtelung annähernd unleserlich werden. Wir hatten da mal 'nen Job mit über 170 Mio. Sätzen in der größten Tabelle, gejoint mit ca. 'nem halben Dutzend weiterer Tabellen in der Größenordnung von 15.000 bis 60 Mio. Sätzen, der eben nicht von der Datenbank sortiert wurde und wir nach 2,5 Tagen noch kein Ergebnis hatten. Nachdem ich gesagt hatte, Schammdrüber, die Datenbank sortiert das, die kann das besser als wir, hatten wir die ersten Ergebnisse nach 25 Minuten und konnten die Ergebnismenge Topdown in die entsprechenden Ausgabedateien schreiben.
Dieses Pauschale "Die Datenbank sortiert nicht" oder "Alles macht die Datenbank" ist von beiden Seiten her kontraproduktiv. Man muss bei jedem Job dadurch, auszuarbeiten, was das Beste ist. Ich halte es für falsch, für irgendwelche Aufgaben bestimmte Vorgehensweisen grundsätzlich für Tabu zu erklären. Ob die von mir beschriebenen Möglichkeiten auch für
SQL-Server geeignet sind, weiß ich nicht, für
Access und dBase ist es mit Sicherheit nichts und für Interbase, Firebird, DB2, Postgres und wie sie alle heißen, habe ich keine Erfahrungswerte. Für Oracle ist meine Erfahrung, lass es die Datenbank machen, sie kann es besser als wir mit unseren Programmierkenntnissen und Werkzeugen.