SQL Techniken in Verbindung mit Subfile

[harkne]

@Bender,

genau das ist im Programm bereits drin. Der Benutzer kann auf 3 verschiedene Spalten klicken zum Sortieren und hat im Header Bereich mehrere Auswahlmöglichkeiten. Außerdem gibt es ein Feld zum Positionieren auf die sortierte Spalte. Das geht auch alles. Bisher wurde die Subfile immer seitenweise nach vorn gefüllt, dies wollte ich jetzt umstellen auf nur das Füllen was man sieht. Nur das ist die Änderung im Programm.
Die Umstellung deshalb, weil beim Positionieren bisher das ganze Resultset durchgelesen werden musste bis man an der entsprechenden Stelle war. Beim Positionieren wurde dann auch gleichzeitig die Subfile mitgefüllt. Habe ich haber 2,5 Mio Sätze dann dauert das und vor allem ist bei Satz 10000 in der Subfile Schluss. Deshalb die Umstellung auf eine Subfile in der nur gefülllt ist was man sieht und ich hatte gehofft dass dann ja die Positionierung schneller geht da ich ja direkt aufsetzen kann. Dann ist mir aber das Problem mit dem Rückwärtsblättern aufgefallen da ja keine Daten vorher im Recordset da sind. Deshalb kam meine ursprüngliche Frage.

@Fuerchau
Hatte ich ja bereits geschrieben dass selbstverständlich bevor der Benutzer eine Auswahl eingibt, nochmal geprüft werden muss ob der Satz da ist oder nicht. Ich habe ja auch geschrieben, dass ich kein Problem damit habe wenn die Sätze die durch andere Anwender geändert hinzugefügt oder gelöscht wurden nicht gleich aktuell sind. Aber bitte. Wenn ich selbst einen Satz lösche oder auch hinzufüge über das Programm, dann hätte ich in der Anzeige auch gerne die Änderungen. Bei einer vorwärts gefüllten Datei ist das aber etwas problematisch da ich das ja manuell machen muss. Deshalb haben wir auch bisher (ohne SQL) bei kleinen Datenmengen wieder neu eingelesen oder aber eben eine Subfile verwendet in der nur das drin steht was man auch sieht. Auch das Positionieren ist mit SETLL und READ unproblematisch aber wenn wie bei diesem Programm es verschiedene Sortiermöglichkeiten und Auswahlen gibt, dann würde ich gerne nicht alles im Quellcode abfragen müssen sondern verwende SQL
Für mich ist es jetzt nur wichtig wie kann ich ein SQL auf eine große Datenmenge absetzen, dass es so schnell wie möglich ein Ergebnis liefert.

@Hauser
Ich spekuliere nicht ich frage und probieren kann ich nur Sachen die ich weiß. Deshalb bin ich der vielen Antworten hier sehr dankbar. Denn damit kann ich viele Sache probieren. Aber es ist nun mal so dass wenn ich ein SQL zum 1. mal absetze es langsamer ist als beim 2. mal. Wenn ich jetzt verschiedene Techniken probiere und er mir bei einer Technik wegen des Abrufs der vorherigen Technik ein schnelleres Ergebnis liefert bin ich nicht viel schlauer, deshalb auch meine Fragen. Natürlich werde ich alles versuchen zu probieren, aber auch der Code sollte am Ende noch wartbar bleiben.
Das mit dem LIMIT ist aktuell auch mein Favorit. Bis jetzt. Aber ist der OFFSET wirklich nötig, wie gesagt kann man auch auch den >= mit ins SQL machen. Natürlich weiß ich mal wieder nicht was schneller ist :-)
Vielen Dank für den Quellcode

@alle
Vielen lieben Dank für die vielen Vorschläge und Anregungen und Hilfe. Ich habe in 2 Tagen einiges dazu gelernt.

Viele Grüße Harald

[Fuerchau]

Ein SQL ist immer beim 1. Mal langsamer als ab dem 2. Mal.
Beim 1.Mal müssen Zugriffswege analysiert werden sowie diverse andere Dinge.
Wenn der SQL nicht geändert wird, ist es beim 2. Mal deshalb schneller, weil eben alles bereits optimiert wurde.
Änderst du den SQL (weil er ja dynamisch ist), fängt eben alles wieder von vorne an.
Wenn ein SQL dann geschlossen wird, werden beim 1. Mal alle betroffenen Dateien ebenso geschlossen Beim Schließen des 2. Mal bleiben dann die geöffneten Dateien auch offen.

Und wie bereits gesagt: Deine Anforderung erledigst du am schnellsten mit einem scrollable sensitive Cursor. Nach dem Löschen oder verändern positionierst du eben um N Sätze rückwärts und füllst neu.
Beim vorwärst blättern liest du einfach weiter.
Beim umsortieren oder ändern des Filters machst du einen neuen Open.

Dein Problem mit dem Key >= xxx löst du ja auch nicht wenn du dir nicht in einer Tabelle die Schlüssel je Seite merkst (was ich in anderen Programmen schon durchaus gesehen habe).
Du musst dir dann die Keyvalues in einer DIM-Struktur je Seite den 1. Schlüssel merken und kannst beim rückwärts blättern dann korrekt wieder positionieren.
Dazu bedarf es allerdings auch bei der Sortierung einer Ergänzung zu größerer Eindeutigkeit (z.B. einer Identity-Spalte), denn wenn du 3 Seiten lang den Namen "Müller" angezeigt hast, möchtest du beim Rückwärtsblättern ja auch die 2. Seite von "Müller" ansehen.
Da eine DS (auch mit Dim) auf 16MB beschränkt bist, kannst du bei einer Schlüssellänge von 100 immerhin noch 160.000 Seiten verwalten.
Ich denke nicht, dass dies ein User schafft, alle Seiten sinnvoll durch zu blättern. Der Tag hat ja nur 86400 Sekunden.

Beim Sensitive Cursor positionierst du einfach 2xN Zeilen zurück. Wenn dann ein Satz dazwischen eingefügt wurde ist das letztlich ja auch egal.

[harkne]

Also ich werde das jetzt im 1. Step wie folgt versuchen.

Bei der ersten Anzeige gibt es ja noch keine vom Benutzer festgelegte Sortierung oder Auswahl also werde ich ein SQL ausführen mit LIMIT 15. Dies werde ich immer machen wenn eine Umsortierung oder eine Selektion von Seiten des Benutzers erfolgt.

Beim ersten vorwärtsblättern, werde ich das gleiche SQL ohne LIMIT und dann immer 15 Sätze beim vorwärtsblättern vorlesen (Scrollable sensitive Cursor fetch next)

Beim rückwärts blättern das gleiche in umgkehrer Reihenfolge (fetch prior)

Jetzt halt die Problematik wenn er positionierten möchte.
Falls er positioniert werde ich das SQL wieder absetzen diesmal aber mit WHERE Keyfeld >= Benutzereingabe

Das geiche wie oben.

Falls er rückwärts blättert (und positioniert hatte) werde ich die Variante für einen 2. Cursor von Bender verwenden. Bei dem die Daten vor der Positionierung in umgekehrter Reihenfolge gelesen werden aber mit der selben vorgehensweise wie beim 1. Cursor.

Bitte kurz abnicken :-)

[Fuerchau]

Muss ich das verstehen?
Warum Limit 15 wenn du doch nach 15 Zeilen fertig mit dem Lesen bist?
Beim Blättern nach vorne einfach weiter lesen, beim Blättern rückwärts einfach 30 Zeilen rückwärts positionieren und wieder füllen.
Bei einem Filter mit "Where"-klausel ergänzen und wieder öffnen.
Bei einer Sortierung mit "order by" ergänzen und wieder neu öffnen.
Beim Blättern brauchst du nichts zu ändern.

Aber warum einfach, wenns auch kompliziert geht;-).

[harkne]

Das genau will ich doch machen, klar ob man bei der ersten Seite ein LIMIT15 macht oder nicht kann man sich überlegen. Das Problem ist und bleibt die Positionierung. Wenn ich jetzt die erste Seite anzeige und der User sagt ich möchte zu Müller positionieren. Soll ich dann das Telefonbuch durchlesen bis ich bei Müller bin?

[Fuerchau]

Das halte ich eher für einen Filter. Das kann man einem User auch erklären.
Wenn man mit "Müller" aufsetzt, wird erst ab Müller gelesen. Ein Rückwärtsblättern würde ich da ausschließen.
Suche ich was anderes als Müller, gebe ich einen neuen Suchbegriff ein.

Ich würde die Eingaben auch als Filter deklarieren. Wenn kein "Müller" da ist, wird auch kein "Neumeier" mehr angezeigt.

Das ist doch wie auf Webseiten (wie z.b. Fahrzugsuche) auch: Wenn es zu viele Ergebnisse in der Suche sind soll man weiter einschränken.

[harkne]

Naja im PDM kann ich sowohl einschränken wie auch positionieren, da lässt er mich dann auch rückwärts blättern nach dem Positionieren

[Fuerchau]

Nun ja, eine Liste von Teildateien ist auf 32768 beschränkt.
Du redest aber von mehreren Millionen Zeilen.
Es ist halt immer eine Sache, wie man eine Anwendung verkauft.
a) schnelle Suchunterstützung
b) mit den Augen suchen
Ich würde (auch schon wegen meiner Augen) Methode a) preferieren.

[harkne]

OK, vielen Dank. Vorschläge habe ich ja jetzt genug.