Ich verstehe nicht warum die Diskussion immer wieder dahin abgleitet ob es sinnvoll ist so viele Daten zu laden. Ich habe nie gesagt, dass irgendjemand durch 100000 oder gar 1.4 Mio Datensätze blättern will.
Als ich das Pulldown vor 30 Jahren eingeführt habe, hat man in SAP noch mühsam über Filter gesucht. Vor ca. 10 Jahren hat Google angefangen nicht nur das anzuzeigen was genau dem Suchbegriff entspricht sondern eine "unscharfe" Suche.
Um dies auch bei langsamem Netz zur Verfügung zu stellen, lade ich eben alle Nr. Das "verschwendet" ca. 135MByte. Zugegeben nicht ganz wenig aber wenn ich seh was Office-Anwendungen so verbraten habe ich kein schlechtes Gewissen und viele der Benutzer sind froh, dass sie auch schnell mal 2 Nummern zurück blättern können. Klar müssen die Daten auch übers Netz, aber nur ein mal. Danach würde ich nur noch die geänderten Daten nachladen und die halten sich sehr in Grenzen. Wenn ich laufend rund ums Tipergebnis lade ist komm ich über dne Tag gesehen wohl auf ähnliche Ergebnisse. Und wenn ich meine Netzload mit der von SAP vergeiche, die in derselben Firma eingesetzt wird, dann brauch ich mir wenig Gedanken machen, ob ich mehr optimieren muss.
Ein Beispiel ist in dem angehängten Bild zu sehen, wo das
SQL nicht ganz einfach wäre um auch die Nummern anzuzeigen die vor dem ersten eingetippten Buchstaben H stehen. Und da die Serien-Nr. vielen unterschiedlichen Systematiken unterliegen, weiß ich nicht was direkt vor H kommt. Ausser ich ladem mal sehr großzügig um H herum.
Es geht aber auch gar nicht um 1.4 Mio Datensätze sondern darum wie ich den Inhalt eines Queries schnell und threadsafe an den Maintread übergebe. Und da ist das satzweise übergeben nicht die schnellste Lösung. Wie gut die Lösung letztlich ist, lässt sich eben am einfachsten mit vielen Daten testen. Wenn die schnell gehen dann sind wenig Daten absolut kein Problem.
Zur Bearbeitung lade ich immer nur den Datensatz, den ich tatsächlich brauche.
Zitat
Baum-Darstellung
