Abfrage über mehrere Felder optimieren

[jobo]

Zitat von Dejan Vu:

So so. Du willst mir also Dämlichkeit unterstellen. Nun denn, wäre nicht das erste Mal.

Ja, wann akzeptierst Du das endlich!? Wie oft soll ich es noch versuchen?


Es ging mir darum, dass die beiden Bereiche nicht so ohne weiteres vergleichbar sind. Und zur Usability gehört halt (für mich) auch Geschwindigkeit, die der TE aber nicht liefert, was seine Kunden zu Recht bemängeln.
Was mich an dem Vergleich stört, auch bei der Kölner Phonetik ist die Unschärfe. Ich will am liebsten einen(!) Volltreffer sehen bei meiner Suche und nichts anderes. Der Begriff des Rankings hilft da schon etwas weiter, ist in Stefans Vorschlag aber erstmal nicht drin. Eine unscharfe Suche ohne Ranking wäre m.E. für die Tonne.

Es gab mal sone Pirelli Werbung (nein nicht die, die andere, im Fernsehn), die endet mit den Worten, Power is nothing without control.
Also ich persönlich bevorzuge differenzierte Suchmöglichkeiten vor der Rundumschlagmethode mit (zweifelhaftem) Ranking(algorithmus).

[nahpets]

@jobo
Naja, bei der Kölner Phonetik gibt es kein Ranking oder eine Gewichtung.
Du sagst natürlich zu Recht: Wenn ich Müller suche, will ich Müller finden, wenn ich Maier suche, will ich Maier finden und nicht auch noch/oder Mayer und Meier und Meyer oder gar noch Mair und Meir...

Prinzipiell ziehe ich die genaue Suche einer Suche ala: "Schaun wer mal, was es da sonst in der Richtung noch so geben könnte" vor. Das stört mich auch bei den Suchmaschinen, wenn ich nach "Delphi Source Kölner Phonetik" suche, will ich genau das finden, wo diese vier Wörter vorkommen, aber als Suchergebnis erhalte ich ca. 16.000 Treffer, aus denen ich mir dann das Passende raussuchen muss. Weniger könnte hier also durchaus mehr sein.

Aber eine Sucheanforderung, wie sie hier vom TE dargestellt wurde, kann man für eine genaue Suche nicht wirklich nutzen. Die Anforderung scheint doch eher dergestalt zu sein: "Suchen Sie mir alles was ich in einem Feld eingegeben habe überall in der Datenbank". Von einer genauen Suche ist das doch eher sehr weit entfernt.

Die Suche mit "%LIKE%" bedeutet für mich eine unscharfe Suche und bei der hier vorliegenden Aufgabenstellung dachte ich mir, mach einen Vorschlag, der halt etwas schneller unscharf ist. Natürlich weiß ich für den konkreten Fall nicht, ob's tatsächlich eine sinnvolle Alterantive ist, aber so als Denkanstoß eventuell brauchbar sein könnte.

Den von mir gemachten Suchvorschlag könnte man ja durchaus ohne Kölner Phonetik umsetzen, in dem man eine entsprechende Wortliste und die zugehörige Referenztabelle pflegt. Auch das würde die Geschwindigkeit der Suche schon deutlich beschleunigen.

[p80286]

@Nahpets
Ich kann Deine Begeisterung für "Köln" verstehen, Ich hab damit auch schon DB-intern Abgleiche durchgeführt.
Aber ich habe den Eindruck, daß wir uns etwas von der Ausgangsfrage entfernen. Was zunächst einmal zu klären wäre, was wird als Antwort auf "Mair" erwartet. 42 wahrscheinlich nicht.

Gruß
K-H

[jobo]

Zitat von p80286:

@Nahpets
Ich kann Deine Begeisterung für "Köln" verstehen ..
was wird als Antwort auf "Mair" erwartet. 42 wahrscheinlich nicht.

42 könnte tatsächlich ein Ergebnis sein und zwar das Ranking oder eine Komponente davon. Die Levenshtein-Distanz als Ranking könnte man ja tatsächlich mit den unscharfen Ergebnissen aus Köln kombinieren. Natürlich angewendet auf Suchwort und Echtdaten in den Treffern, nicht auf die Codierung.
In meiner Lieblingsdatenbank gibt es die Levenshtein-Distanz bereits als Funktion, kann also direkt ins SQL eingebaut werden, sehr praktisch.
42 wäre natürlich ziemlich mies als Distanz.

[Jumpy]

Zitat von jobo:

42 wäre natürlich ziemlich mies als Distanz.

Zumal Deep Thought 7.5 Millionen Jahre gebraucht hat, um es zu errechnen

[SvB]

Ich wollte noch mal eine Rückmeldung geben, wie ich jetzt die Suchmaske angepasst habe. Es ist daraus jetzt ein Zwitter geworden.

Ich habe eine Combobox in die Maske hinzugefügt, die den Eintrag <Alle Felder> und jeweils die Felder einzeln enthält, die in der Suchmaske angezeigt werden.
Wenn der Benutzer <Alle Felder> ausgewählt hat, dann läuft die Suche wie bisher in allen Felden wie in meinem Beispiel mit LIKE ''%BÄCKEREI%''. (Also ohne Index und langsam)
Wenn der Benutzer ein spezielles Feld wie z.B. die Kundennummer auswählt, dann wird "SELECT FROM <Tabelle> WHERE Kundennummer = <Eingabe>" ausgeführt. Hierbei wird dann der Index verwendet und das geht rasend schnell.
Somit kann der Benutzer jetzt selbst wählen wie er sucht. Entweder wie bisher und kann eventuell Däumchen drehen bis was kommt oder er überlegt sich vorher genau was er suchen will und macht es dann auch so.

Dann habe ich noch das Grid durch das DevExpress Grid ausgetauscht und dort alle Filtermöglichkeiten freigeschaltet. Damit hat der Benutzer zusätzlich die Möglichkeit in den zuvor gesuchten Daten zu filtern.
Wenn sich jetzt noch einer beschwert, dann weiß ich im Moment auch nichts mehr.