Abfrage über mehrere Felder optimieren

[SvB]

Ich habe eine Suchmaske für Beleg, in der folgende Felder angezeigt werden: Belegnummer, Belegdatum, Kundennummer, Kundenname 1, Kundenname 2, Straße, PLZ, Ort, Seriennummer. Das Belegdatum ist ein TIMESTAMP, alle anderen Felder sind VARCHARs. Die Felder sind alle in der selben Tabelle. Zu jedem Feld gibt es auch einen eigenen Index, da ich diesen auch für andere Dinge benötige.
In der Suchmaske gibt es ein Eingabefeld, in den etwas beliebiges eingegeben werden kann und in den oben genannten Feldern gesucht werden soll. Im Moment baue ich mir ein SQL mit OR und LIKE zusammen. Beim Kunden dauert die Abfrage je nach dem zwischen mehreren Sekunden bis zu 3 Minuten und ist daher nicht optimal. Der Anwender ist damit nicht sehr zufrieden.
Da ist kein 100%-iger Datenbank Profi bin, weiß ich im Moment nicht wie ich das verbessern kann. Ich wäre für einige Tipps sehr dankbar.

[waldforest]

Hallo,
über welche Datenmenge erfolgt die Abfrage, kannst du deine Abfrage mal hier einstellen ?

Suchst du immer in alle Feldern über ein Eingabefeld.
Eine Abfrage mit direktem Bezug zum Suchfeld wäre sicher optimaler.

[Dejan Vu]

Bei anderen DB würde ich eine derartige Anforderung über einen Volltextindex lösen. Dabei werden alle zu durchsuchenden Felder mit ' ' als Trenner konkateniert und in einer separaten View indiziert.

Aber Du hast leider FB, der kann das nicht (Nachrüsten geht wohl, mit kleinen Klimmzügen)

[SvB]

Hi,

aktuell sind es ca. 400.000 Datensätze.

Die Abfrage sieht z.B. so aus:
SELECT ID,BEL_SERNr,BEL_Dat,BEL_KD_Nr,BEL_KD_SEQ,BEL_KD_N ame1,BEL_KD_Strasse,BEL_KD_PLZ,BEL_KD_Ort,BEL_MA_S erNum,BEL_TechNr FROM QRY_BELEGSEARCHBEL_SERNR WHERE ((UPPER(BEL_SERNR) LIKE ''%BÄCKEREI%'') OR (UPPER(BEL_KD_NR) LIKE ''%BÄCKEREI%'') OR (UPPER(BEL_KD_SEQ) LIKE ''%BÄCKEREI%'') OR (UPPER(BEL_KD_NAME1) LIKE ''%BÄCKEREI%'') OR (UPPER(BEL_KD_STRASSE) LIKE ''%BÄCKEREI%'') OR (UPPER(BEL_KD_PLZ) LIKE ''%BÄCKEREI%'') OR (UPPER(BEL_KD_ORT) LIKE ''%BÄCKEREI%'') OR (UPPER(BEL_MA_SERNUM) LIKE ''%BÄCKEREI%'') OR (UPPER(BEL_TECHNR) LIKE ''%BÄCKEREI%'')) ORDER BY BEL_SERNR ASC

Es ist nur ein Eingabefeld für die Suche. Hier im Beispiel wird jetzt nach "Bäckerei" gesucht, wobei das natürlich in der Belegnummer oder der PLZ keinen Sinn macht. Der Benutzer soll der Einfachheit halber nur "einen" Suchbegriff eingeben und es soll in allen Feldern gesucht werden. Mir ist bewusst, dass dies nicht optimal ist und ich suche deshalb nach einer anderen und besseren Lösung.
Zukünftig möchte ich noch einbauen, dass z.B. durch Leerzeichen getrennt mehrere Suchbegriffe eingegeben werden können wie z.B. "Bäckerei München". Das macht das Ganze aber auch nicht einfacher. Zunächst benötige ich aber eine Verbesserung der aktuellen Situation und bin für jeden Tipp und Vorschlag dankbar.

Wie ich aus Deiner Info sehe, wäre es besser, wenn ich zum Suchbegriff angebe, in welchem Feld gesucht werden soll. Richtig?

[DeddyH]

Die größte Bremse ist das vorangestellte "%", da damit kein Index der Welt mehr greifen kann.

[Sir Rufo]

Zitat:

Zitat von DeddyH (Beitrag 1312596)

Die größte Bremse ist das vorangestellte "%", da damit kein Index der Welt mehr greifen kann.

Wird der Index nicht schon durch das Upper ausgehebelt?

Und der Name QRY_* lässt mich irgendwie an eine View denken ...

[SvB]

Stimmt. Mit dem vorangestellten % nützt kein Index was, hab noch mal selbst etwas recherchiert. Das ist schon mal sehr schlecht. Was mach ich aber wenn in einem Feld "- Cafe Quirl -" (ohne die ") steht und ich nach "Cafe" suchen möchte, dann bekomme ich den Datensatz ja nicht zurück. Irgendwie muss ich schon so suchen können, dass der eingegebene Text irgendwo im Feld stehen kann.

Mit dem Upper muss ich mir auch noch mal ansehen.
QRY_* ist eine View, da hab ich schon mal was drüber probiert, hat aber auch keine Geschwindigkeitsverbesserung gebracht.

Ich glaube es ist wirklich am besten, wenn der Benutzer angibt, in welchem Feld er suchen möchte. Wenn er z.B. die Belegnummer eingibt, dann kann das Programm ja direkt nur mit diesem Feld suchen. Entsprechend mit dem Datum, der Kundennummer usw. Bei den anderen Feldern ist es genau so. Das Wort "Cafe" wird auch nur im Namen gesucht, im "Ort" gibt es das nicht.

[nahpets]

Hallo,

ist like bei FB Casesensitive? Bei manchen Datenbanken ist bei like die Groß-/Kleinschreibung nicht von Belang.
Wenn FB die Groß-/Kleinschreibung bei like nicht beachtet, kannst Du die Uppers schonmal weglassen.

Dann ein schräger Vorschlag:

Datenbank um eine Spalte Upperdaten (oder wie auch immer Du sie nennen magst) erweitern. Spalte ausreichend "breit" dimensionieren, so dass alle Werte der zu durchsuchenden Spalten aneinandergehängt da rein passen.

Deine Abfrage ist dann "nur noch"

Code:

SELECT ID,BEL_SERNr,BEL_Dat,BEL_KD_Nr,BEL_KD_SEQ,BEL_KD_N ame1,BEL_KD_Strasse,BEL_KD_PLZ,BEL_KD_Ort,BEL_MA_S erNum,BEL_TechNr FROM QRY_BELEGSEARCHBEL_SERNR WHERE Upperdaten like '%BÄCKEREI%'

Die Spalte muss dann halt bei jeder Änderung (per Trigger?) mitgepflegt werden. Jedenfalls muss FB dann nicht bei jeder Abfrage die ganze Tabelle in Großschrift umwandeln.

Und wenn Du die Daten in der Upperdaten-Spalte noch mittels Kölner Phonetik ablegst und den eingegebene Suchbegriff ebenfalls entsprechend behandelst, wird die Suche auch noch fehlertolerant. Es werden dann nicht nur die Bäckereien sondern auch die Baeckereien gefunden und sowohl Cafe als auch Café (dann aber auch Kaffee). Und ob - davor, dahinter oder dazwischen stehen, wird auch irrelevant. Eignet sich aber nur für die Textsuche und nicht für die Suche nach Zahlen oder Buchstaben-/Zahlenkombinationen.

Sofern der obige Ansatz zu einem Geschwindigkeitsvorteil führt, könnte die Kölner Phonetik zu einem Suchkomfort führen, der keinen zusätzlichen Aufwand bei der Suche erfordert und einen neuen Flaschenhals generieren könnte.

Eine Implementierung der Kölner Phonetik findest Du hier, sofern es Dich irgendwann interessieren sollte.

[Dejan Vu]

Zitat:

Zitat von DeddyH (Beitrag 1312596)

Die größte Bremse ist das vorangestellte "%", da damit kein Index der Welt mehr greifen kann.

Schade, dass das bei FB so ist. Denn es muss nicht sein. Ein 'Index Scan' ist wesentlich schneller als ein 'Table Scan', weil weniger Daten zu laden sind.

[Perlsau]

Zitat:

Zitat von SvB (Beitrag 1312598)

Ich glaube es ist wirklich am besten, wenn der Benutzer angibt, in welchem Feld er suchen möchte. Wenn er z.B. die Belegnummer eingibt, dann kann das Programm ja direkt nur mit diesem Feld suchen. Entsprechend mit dem Datum, der Kundennummer usw. Bei den anderen Feldern ist es genau so. Das Wort "Cafe" wird auch nur im Namen gesucht, im "Ort" gibt es das nicht.

Das mache ich quasi schon immer so. Manchmal gibt es sogar nur ein Feld, das durchsucht werden darf oder nur ein paar wenige – eben die, die überhaupt Text enthalten können. Wiederkehrende Inhalte wie Kundennamen oder Branchen-Bezeichner (Bäckerei) oder Ortnamen usw. sollte man sowieso in einer eigenen Tabelle führen und in der Haupttabelle nur die jeweilige ID mitführen. Das erleichtert erstens die Suche und schützt zweitens vor Fehleingaben (Baeckerei - Bäckerei - Bäkerei - Bäckerie - Beackerei, Bäcker, Becker ... wenn man sich allein die mangelhafte Rechtschreibung etlicher Forenuser anschaut ...). Wenn nur eine Kunden-Nummer gesucht wird oder ein Kunde, dann sollte in der Haupttabelle, in der der Kunde lediglich durch deine ID repräsentiert ist, nur nach dieser ID gesucht werden müssen. So eine eierlegende Wollmilchsausuche kann letztlich nur sehr langsam sein, wenn man ständig alle Begriffe in allen Feldern zu finden versucht: Du mußt dir klarmachen, daß dabei jedes zu durchsuchende Feld auf die Suchbegriffe hin abgeklopft werden muß, das dauert eben.

Noch ein Hinweis: Indiziere Felder oder Feldgruppen, die häufig durchsucht oder lokalisiert werden müssen. Das bringt schonmal enorme Geschwindigkeitsgewinne.

[mkinzler]

Zitat:

Wird der Index nicht schon durch das Upper ausgehebelt?

Kommt auf den Index an. Bei eienm entsprechenden expression index ist das egal.

[hoika]

Hallo,
wie sieht denn der Query-Plan aus?
Bekommt man z.B. mit IB-Expert.


Heiko

[jobo]

Statt "LIKE" könnte man "CONTAINING" nehmen, das umgeht schonmal das "Upper"-Problem. Ich weiß allerdings nicht, wie geschickt es vorhandene Indices nutzt.
Die vielen "OR" bzw. das Suchverfahren einen Suchwert in vielen Feldern zu suchen, ist aber wohl das größere Problem. Zumindest deutet die Suchzeit darauf hin, dass es nicht um einen, sondern viele Full Table Scans geht.
Wenn man dieses merkwürdige Verfahren beibehalten will, kann man lieber gleich per SP und Cursor alles einmal abklappern.

Ansonsten ist es natürlich empfehlenswert, gezielt zu suchen. Wenn es um 's Datum geht, dann bitte nur auf dem Datumsfeld und natürlich nicht per Wildcard (wenn es denn wirklich ein DATE Feld ist).
Eine solche Zusammenfassung der Suche auf mehreren Feldern ist m.E. nur vertretbar, wenn sich
a) die Inhalte vom Nutzer nicht unterscheiden lassen
b) die Datenstrukturen sich absehbar nicht sinnvoll differenzieren lassen
c) die Suchwerte strukturell so unterschiedlich sind, dass nach der Eingabe bzw. aus dem Eingabewert/-formatierung eindeutig auf das Feld geschlossen werden kann. Also z.B. Artikelnummer, Preis, Bestelldatum oder Artikelbezeichnung

Suchen mit potentiell großer Ergebnismenge sollten ebenfalls unterbunden werden, sie kosten enorm Ressourcen und bringen keinen Nutzen vür den Anwender. Also z.B. Suche nach Preis im 1 Euro Shop.

[Dejan Vu]

Es gibt noch einen sinnvollen Grund, so eine Suche à la Suchmaschine (als nur mit einem Eingabefeld) zu machen: Bequemlichkeit, aka 'usability'.

Ich suche nach einem Hr. Müller in Wattenscheid. Also gebe ich ein 'Müller Watt' und meine Routine liefert mir alle Müller in Wattenscheid. Aber klar, es findet auch alle Wattwanderer in Müllersried. :lol:

Und ich muss nicht 'umständlich' die einzelnen Suchfelder ausfüllen. Das ist bequem, einfach, und genau so, wie ich es von GoogleBing gewohnt bin.

Die Frage ist erlaubt, ob das Ausfüllen individueller Suchfelder umständlich ist, oder nicht. Das bestimmt der Kunde. Bei uns möchte er nur ein Eingabefeld.

[jobo]

Zitat:

Zitat von Dejan Vu (Beitrag 1312656)

Bequemlichkeit

hat ihren Preis

Zitat:

Zitat von Dejan Vu (Beitrag 1312656)

'usability'

Fail bei 3 Minuten Antwortzeit

Zitat:

Zitat von Dejan Vu (Beitrag 1312656)

Die Frage ist erlaubt, ob das Ausfüllen individueller Suchfelder umständlich ist, oder nicht. Das bestimmt der Kunde. Bei uns möchte er nur ein Eingabefeld.

Es gibt natürlich für einen Entwickler nichts besseres als einen anspruchsvollen Kunden, der sich diesen Anspruch auch leisten kann. :)

Und zum Thema Google/Bing. Die (wollen) verdienen ihr Geld genau damit. Und sie liefern technisch gesehen etwas vollkommen anderes ab, als hier gefragt ist. Google/Bing sind schnell und die Ergebnisse sind nicht überprüfbar, also viel gebe ich darauf nicht, auch wenn die Handhabung verheißungsvoll ist. (Millionen Fliegen irren ja bekanntlich nicht)

[nahpets]

Hallo,

habe vor Jahren mal 'ne Suchmaschine (für beliebige Texte) geschrieben, die war und ist sauschnell, auch wenn sie eine Volltextsuche enthält. Das Vorgehen ist ganz einfach:

Texte werden in Einzelwörter zerlegt. Diese Wortliste wird von Dubletten bereinigt, so dass es eine eindeutige Liste wird.

Es gibt (beispielhaft) insgesamt drei Tabellen:

1. Daten : DatenID : Integer; beliebige Spalten...
2. Wortliste : WortID : Integer; Wort : varChar
3. Referenzliste: DatenID : Integer; WortID : Integer

Vorgehen:
Beim Speichern eines Satzes in der Datentabelle werden alle Felder, die im Volltextindex benötigt werden, zu einem Text zusammengedaddelt.
Dieser Text wird in Einzelwörter zerlegt.
Jedes, noch nicht in der Wortliste enthaltene, Wort wird in die Wortliste eingefügt, die Wortliste ist also eine eindeutige Liste.
Es wird die Referenzliste gepflegt. Für jedes Wort des Datensatzes wird ein Eintrag DatenID <-> WortID in die Referenzliste eingefügt.

Bei der Suche muss man dann nur (per Index) alle Sätze suchen, die zum eingegebenen Wort passen.

Das geht (beispielhaft) per:

Code:

select a.* from Daten a, Referenzliste b, Wortliste c where a.DatenID = b.DatenID and b.WortID = c.WortID and c.Wort = :Eingabe

(Selbst ein Like auf die Wortliste sollte hier nicht zum Performanzkiller werden.)

Dafür braucht man auf der Datentabelle einen Index auf der DatenID, auf der Referenztabelle einen auf DatenID und einen auf WortID und für die Worttabelle einen auf Wort.

Wenn man nun die Wortliste grundsätzlich nur in Kleinschreibweise befüllt, benötigt man für den Suchbegriff nur einmal ein Lower und spart sich die ganze Schreibweisenveränderung in jedem SQL.

Für eine schnelle Suche muss man sich die Daten nunmal normalisieren und kommt mit einer Tabelle und einem SQL ala "Liebe Datenbank, guckt doch mal, ob Du nicht eventuellunterumständenvielleicht irgendwo was passendes finden könntest" nicht aus.

Dieses sehr ungenaue "Habenmöchten" dauert einfach zu lange, wenn man nicht vorher für eine passende Struktur gesorgt hat.

Das "Wortlisteerstellen" ist (mit Delphi) sehr einfach.
Alle benötigten Felder in eine Stringliste, Delimiter auf Blank und DelimitedText abrufen. Sort aufrufen, Dubletten raus und schon kann die Wortliste in der Datenbank gepflegt werden.

Hier im Beispiel sollte die Änderung des "Systems" in ein- bis zwei Tagen in ausgereifter Form möglich sein.

Wenn man nun noch (wie oben in 'nem anderen Beitrag beschrieben) die Kölner Phonetik für die Wortliste nutzt, dann kann man damit ähnlich unscharf Suchen, wie wir es von den Suchmaschinen gewohnt sind. Meier findet dann auch Maier und Mayer und Meyer und Hofmann findet auch Hoffmann..., Cafe und Café werden nicht mehr unterschieden...

Soll der Suchbegriff mehrere Wörter enthalten (können), dann passt man das SQL halt an:

Code:

select a.* from Daten a, Referenzliste b, Wortliste c where a.DatenID = b.DatenID and b.WortID = c.WortID and c.Wort in (:Wort1, Wort2, ..., WortN)

Auf Like kann man dann ganz verzichten und kann immer per Index suchen.

Wenn das dann (mit zusätzlichem Suchkomfort) nicht schnell wird, hat man ein vollkommen anderes Problem, das nur zufällig bei der Suche deutlich aufgefallen ist.

[jobo]

Eine schöne Sache, aber hier wäre ich vielleicht etwas vorsichtiger gegenüber dem TE:

Zitat:

Zitat von nahpets (Beitrag 1312707)

Hier im Beispiel sollte die Änderung des "Systems" in ein- bis zwei Tagen in ausgereifter Form möglich sein.

Neben der Implementierung, braucht es Tests und Migration (der Kundendaten). Passt eine Kölner Phonetik auch für französische Kundennamen, türkische oder polnische ..? Wenn nicht, was dann? Der anspruchsvolle Kunde wird dann vielleicht sauer, weil er sagt, er hat viel Geld ausgegeben für ein Verbesseung und nun funktioniert es nur für deutsche Datenbankeinträge.

[nahpets]

Also mit dieser "Methode" (sprich Kölner Phonetik) haben wir den kompletten Datenbestand der Telekom (also alle von denen gelieferten Adressen) gegen andere Systeme abgeglichen, um Dubletten zu bereinigen und Systeme, die über keine eindeutigen Zuordnungen, über wie auch immer geartete Schlüssel, verfügten, miteinander abzugleichen. Und die Resultate waren (sind) verblüffend gut. Neben dem Namensabgleich haben wir noch versucht, die Adressen gegen einen vollständigen Adressbestand der Bundesrepublik abzugleichen, so dass wir (im Idealfall) den Namensabgleich quasi "nur noch" auf Hausebene durchführen mussten. Wer sich aber die Qualität der Telefondaten (in Bezug auf Schreibweise, mehr oder weniger offensichtliche Fehler) anschaut, weiß, dass der Abgleich auf Hausebene eher unwahrscheinlich ist.

Gerade bei "ausländischen" Namen treten häufig unterschiedliche Schreibweisen auf, nehmen wir den Vornamen Juri und/oder Yuri, beides kann korrekt sein, in Bezug auf eine konkrete Person ist aber eine der beiden Schreibweisen falsch, wird so aber trotzdem gefunden.
Oder wie ist es bei meinem Vornamen: Stephan oder Stefan? Like hilft hier herzlich wenig.

Oder nehmen wir den aus dem Marokkanischen stammenden Nachnamen Bouauda, gesprochen Bo-u-da. Wer kann diesen Namen, beim erstmaligen Hören sofort richtig schreiben? Bei der Kölner Phonetik ist's egal, er wird gefunden.
Wie schreibt man den türkischen Namen Cigdem, gesprochen eher wie Schiedämm?
Oder wie schreibt man Koslow? Oder doch eher Kozlow? Oder war es Kozlov oder doch Koslov?
Alles ist richtig, aber wie ist die Schreibweise im konkreten Fall? Like mit '%KOSLOV%' hilft mir da herzlich wenig.
Auch hier wird die Kölner Phonetik eine gute Hilfestellung sein.
Aber die Fehlermöglichkeit des "Zuvielfindens" durch die Unschärfe, wird den Zusatzaufwand durch beim letztgenannten Namen ggfls. vierfachen Suchaufwand, sicherlich nicht überwiegen. Zumal ich bei unterschiedlichen Möglichkeiten der Namensschreibweise ja auch erstmal darauf kommen muss, dass der Name auch in anderer Form korrekt geschrieben sein könnte.

Natürlich ist mir klar, dass ich bei der Umsetzung einer derartigen Implementierung den Rückhalt beim Kunden haben muss. Den verschaffe ich mir zuerst und dann setze ich mich an die Umsetzung. Eine derartige Änderung würde ich nie ohne Einverständnis des Kunden vornehmen. Als "einfacher Programmierer" muss ich mir ggfls. auch bei meinem Team-, Projekt- oder Sonstwasleiter, Vorgesetzten, Chef... das Ok holen.
Aber bei der von mir skizzierten Lösung sind nur neue Tabellen erforderlich, der eigentliche Datenbestand muss nicht verändert werden, die technische Änderung ist (sollte) für den Anwender (und ggfls. die Anwendung) vollkommen transparent sein. Dies liegt allerdings auch an der Art der bisherigen Implementierung. Da mir diese nicht bekannt ist, kann ich hier auch keine sinnvollen und verlässlichen Abschätzungen vornehmen. Aber ausgehend davon, dass ich für die Entwicklung und die Datenbankänderungen einen "Freifahrschein" habe, also absolut selbständig entscheiden kann, sollte das in ein bis zwei Tagen umzusetzen sein. Der Datenbestand muss einmal komplett gelesen und gespeichert werden. Es ist also einmalig die zukünftig zu verwendende Speicherroutine für jeden Datensatz aufzurufen. Bei der angegebene Datenmenge sollte das (eigentlich) kein übermäßiges Laufzeitproblem werden.

Eine Implementierung der Kölner Phonetik für Delphi ist hier zu finden: (https://github.com/chaosben/theunkno...erPhonetik.pas)

[Dejan Vu]

Zitat:

Zitat von jobo (Beitrag 1312660)

Zitat:

Zitat von Dejan Vu (Beitrag 1312656)

Bequemlichkeit

hat ihren Preis

Zitat:

Zitat von Dejan Vu (Beitrag 1312656)

'usability'

Fail bei 3 Minuten Antwortzeit

So so. Du willst mir also Dämlichkeit unterstellen. Nun denn, wäre nicht das erste Mal.
Stell Dir vor, man würde das mit einer (wie ich übrigens schon ausführte ;-) ) Volltextsuche kombinieren. Dann wären das eher so um die 0.01 Sekunden Antwortzeit.

Zitat:

Google/Bing sind schnell und die Ergebnisse sind nicht überprüfbar, also viel gebe ich darauf nicht, auch wenn die Handhabung verheißungsvoll ist. (Millionen Fliegen irren ja bekanntlich nicht)

Dann beschäftige dich einfach mal mit Volltextsuche und Rankingalgorithmen.

So, und nun behandeln wir uns wieder mit Respekt und unterstellen dem Anderen weder Dämlichkeit noch fehlendes Knowhow, ok?

So eine Art 'FT für FB' gibt es vielleicht hier: http://www.heise.de/download/firebir...x-1164064.html

Schade, das dieses Feature in FB bisher nicht eingebaut ist.

Thema 'Kölner Phonetik': Ich habe mit einem tokenbasierten Levenshtein sehr gute Ergebnisse erzielt. Es ging um den Abgleich einer Musikdatenbank von 6 Mio Einträgen mit Sendemeldungen aller Rundfunk und Fernsehstationen (ca. 100 Mio). Abzugleichen waren Interpret und Titel. Der Interpret konnte als 'Michael Jackson, 'Jackson, Michael', 'Jakson, Michael' ets geschrieben werden. Problematisch wurde es bei 'P!nk' (ihr offizieller Name ist so), die es als 'Pink' oder auch 'P.I.N.K.' gibt. Das war nicht so einfach.

Die Ergebnisse waren mit der KP vergleichbar.

[nahpets]

@Dejan Vu
Die Levenshteindistanz hat auch schon was, mir ist nur bisher keine Idee gekommen, wie man die sinnvoll in der Datenbank ablegen kann, hier muss man in einer Abfrage konkret zwei Werte mit einander vergleichen, in dem man die Levenshteindistanz berechnen lässt.

Die Kölner Phonetik ermittelt man einmal (pro Wort) und legt sie zusätzlich zum Wort in der Datenbank ab. Für die Eingabe ermittelt man sie ebenfalls und sucht dann in der Datenbank den ermittelten Wert. Da mehrere Worte den gleichen Wert für die Kölner Phonetik haben können, bekommt man hier ggfls. eine höhere Treffermenge.

Bei der Levenshteindistanz müsste man ja dann für 'Michael Jackson' und 'Jackson, Michael' einen Wert ablegen, einen für 'Michael Jackson' und 'Jakson, Michael' ... für alle möglichen Kombinationen von Schreibweisen.
Oder hab' ich hier was nicht verstanden? Die Levenshteindistanz gibt ja letztlich an, wieviele Mutationen erforderlich sind, um aus der Zeichenfolge A die Zeichenfolge B zu erhalten.

Beim dem von Dir beschriebenen Szenario erscheint sie mir aber eine durchaus brauchbare Möglichkeit für die Ähnlichkeitssuche zu sein.
Die Kölner Phonetik würde ja bei den beiden Zeichenfolgen 'Michael Jackson' und 'Jakson, Michael' gnadenlos scheitern, man müsste hier also erst die Zeichenfolgen in Einzelwörter zerlegen und dann nach der "Ähnlichkeit" der Einzelworte suchen und entscheiden, ob's 'ne Übereinstimmung gibt.

Bei dem von Dir beschriebenen (beinahe schon Prosa-)Vergleich dürfte die Levenshteindistanz (zumindest bei einem einmaligen) Vergleich gegenüber den anderen Algorithmen schon fast unschlagbar sein.

Nur aus Neugier: Wie lang hat der Abgleich von den 100 Mio. Sätzen gedauert?

[jobo]

Zitat:

Zitat von Dejan Vu (Beitrag 1312778)

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.:wink:

Gruß
K-H

[jobo]

Zitat:

Zitat von p80286 (Beitrag 1312806)

@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:

Zitat von jobo (Beitrag 1312822)

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

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

[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.