"Live Preview" zum Suchen mittels Texteingabe

[Der schöne Günther]

Ich bin mir nie sicher, ob ich bei meinen ständigen "Wie sollte man diesen Datenbank-Kram eigentlich umsetzen?"-Fragen eigentlich das richtige Unterforum erwische. Das hier ist doch eigentlich eher für konkrete Probleme mit einem ganz bestimmten DBMS, oder? Wäre nett wenn sich ein Moderator mal dazu äußern könnte.

Ich möchte einen relativ simplen VCL-Win32-Client basteln welcher den Benutzer nur mit ein paar Nummern oder einem Freitext-Feld nach ein paar Datensätzen suchen lässt. Die Ergebnismenge wird einfach in ein TDBGrid geworfen.

Ich bin ratlos, wie man so eine Komfortfunktion wie eine "Live Suche" implementieren sollte: Der Benutzer fängt an, Text in ein Edit zu tippen und das Frontend liefert bereits die ersten X Treffer die auf das bereits getippte passen. So wie Web-Suchmaschinen das auch tun.

Es ist noch nicht sicher, ob es über eine lokale DB (wie SQLite) oder einen dedizierten MS-SQL-Server laufen wird. Deshalb kann ich ja schlecht nach jeder Änderung im Edit-Feld neu suchen und auf das Ergebnis warten.

Gibt es eine Art ... Achtung, abgedroschenes Modewort ... Best Practice wie man das im RAD Studio am besten anstellt? Oder kann man das nicht per se sagen da es zu sehr auf das konkrete DBMS und die angebotenen Funktionalitäten dahinter ankommt?

[p80286]

Das ist eine Frage wie Du es darstellst:

Zitat:

Der Benutzer fängt an, Text in ein Edit zu tippen und das Frontend liefert bereits die ersten X Treffer die auf das bereits getippte passen. So wie Web-Suchmaschinen das auch tun.

Meiner Meinung nach bekommst du da nur einen Auszug (die ersten x Einträge) eines Index.
In der Praxis könnte man das so lösen:
in den onChange deines Tedit schreibst Du
If length(suchwort)>3 then Abfrage(select Name from Nametable where name like ''+suchwort+'%''); Ist aber stark von den Daten abhängig, so ab 100 Datensätzen die in Frage kämen kann es holprig werden, kommt aber sehr auf Deine Infrastruktur an.

Gruß
K-H

[mjustin]

Zitat von p80286:

Meiner Meinung nach bekommst du da nur einen Auszug (die ersten x Einträge) eines Index.

Bei einem Index muss man sich natürlich auch fragen, auf welchem "Datenfeld" indiziert wird: nach einer unsichtbar intern hinterlegten "Relevanz", oder in allen Feldern die einfach als sehr sehr langer String zusammengefasst werden - mit oder ohne Gewichtung einzelner Felder, z.B. bei Büchern würde eine Übereinstimmung mit dem Buchtitel einen höheren Stellenwert haben...

[Sir Rufo]

Nach den ersten x Zeichen (3 ist schon mal eine gute Wahl) werden die Daten beim Server abgeholt. Alle weiteren werden dann im TDataSet.OnfilterRecord weiter gefiltert.

[Furtbichler]

Nichts machen, bis der Benutzer aufhört zu tippen. (z.B. Bei jedem Tastendruck einen Timer starten, der auf 100ms eingestellt ist. Im OnTimer des Timers dann die Suche ausführen).

Ich würde das per ADO mit FetchAsync laufen lassen. Bei jedem Neustart der Suche (siehe Timer) wirst Du die aktuelle Query ggf. abbrechen (geht bei FetchAsync ganz einfach) und neu starten. Die Daten kommen vom Server dann schön asynchron, in Happen und alles sieht sehr flüssig aus. Isses auch.

Nur wenn der Server richtig ackern muss (weil eine Suchspalte nicht indexiert ist), dauert das Abbrechen und die Sache kommt ins Stottern. Deshalb nimmt man für eine coole Livesuche auch einen Volltextindex, aber das ist wieder eine etwas andere Geschichte (Indexed View mit PK und Suchtext usw.)

Oder Du machst alles einfach in-memory und spielst mit der OnFilterRecord Geschichte herum. Das ist aber auch erstaunlich langsam, also immer schön im Hintergrund filtern.

Zitat von Sir Rufo:

Nach den ersten x Zeichen (3 ist schon mal eine gute Wahl) werden die Daten beim Server abgeholt. Alle weiteren werden dann im TDataSet.OnfilterRecord weiter gefiltert.

Ich würde das ggf. noch von der Anzahl der zu erwartenden Daten abhängig machen. Wenn da 1000000 Records kommen, wird es vielleicht doch etwas langsam.

Ach, MSSQL ist ideal dafür.