Stringvergleiche in SQL mit Umlauten

Ich kämpfe mich derzeit durch ein Problem wie ich am besten eine effiziente (sprich: schnelle) Suche in einer größeren DB machen soll:
Im wesentlichen hab ich dabei eine Tabelle mit Kundendaten (>40 Mio. Datensätze). Nun soll der User nach bestimmten Kunden "suchen" können und gibt dafür verschiedene Parameter an. Das ist solange kein Problem, solange keine Umlaute vorkommen...

Leider ist der Datenbestand aus Altbeständen übernommen, weshalb oft z.B. ein Herr Müller als Mueller eingetragen ist. Nun stellt sich die Frage: "Wie suche ich nach dem?" 🤔

Ich hab schon ein paar Ansätze durchgedacht, aber keinen wirklich guten gefunden - Irgendwelche Vorschläge?

Bart Simpson

du konntest zb SOUNDEX bzw DIFFERENCE verwenden, oder auch bei Sonderzeichen eine Alternativsuche mit OR hintendranhängen.

Es gibt auch einiges an Tools von Drittherstellern zum Thema "unscharfe Suche".

Ansonsten kann man auch die Benutzer schulen, damit sie wissen das man statt Mayer auch M[ae][iy]er schreiben kann und so auch Möglichkeiten gibt anders heranzugehen.

An SOUNDEX und Konsorten hab ich auch schon gedacht - ist aber zu unscharf. Da krieg ich dann u.U. viel zu viele Ergebnisse, was das Arbeiten sehr erschwert.

Die Variante mit dem OR hatte ich ebenfalls schon im Blick, aber die folgenden Nachteil:
Wenn mehr als ein Umlaut drin ist, dann muss man (eingentlich) alle Variationen per OR erlauben - dass sowas vorkommt ist zwar zugegebnener Maßen unwahrscheinlich, aber es geht ja ums Prinzip 😉

Die Schulung der Mitarbeiter... hmm das wäre ein Ansatz. Aber wie sagt ein Kollege von mir doch immer so treffend: "They can always built a better idiot!" 😁

Was mir noch einfiele, womit ich aber bisher keinerlei Erfahrung hab: Wie sieht's da mit 'ner Volltextsuche aus?

Bart Simpson

Du müsstest doch nur einen Parameter in 2 aufteilen.

Beispiel:
Suche nach 'Müüllär' (mir fällt kein Name mit mehreren Umlauten ein 😉)

Umwandeln in:
(Name = 'Müüllär' OR Name = 'Mueuellaer')

Weil es wird ja wohl nicht vorkommen das ü und ue gemischt sind in deinem Datenbestand.

Gruß,
Tom

Original von Tom
Weil es wird ja wohl nicht vorkommen das ü und ue gemischt sind in deinem Datenbestand.

Tja, wenn dem mal so wäre... Wie gesagt es sind Daten aus "Altbeständen"....

Bart Simpson

Eine Möglichkeit die mir noch einfällt wären die Platzhalter.

Sprich

SELECT * FROM Tabelle WHERE Name = 'M__ller'

Also in deinem Code jeden Umlaut durch __ ersetzen (2 Leerzeichen).

Problem dabei ist aber sicherlich auch, dass du mehrere Treffer bekommst.

Weiss jetzt nicht ob du mich so richtig verstanden hast.

Also normalerweise schreibt ein unbedarfter Mensch (😉) entweder Umlaute oder er schreibt sie halt aus.
Soll heissen ein Datensatz wird denke ich mal nicht gemischt sein, sollte dies dennoch der Fall sein musst du dir über die Implementation eines Phonetischen Algorithmus Gedanken machen.
Aber normalerweise würde ich behaupten das mein Denkansatz in deinem Falle reicht.

Gruß,
Tom

Der _ als Platzhalter steht aber doch immer für genau ein Zeichen...
D.h. M__ller findet zwar Mueller, aber nicht Müller weil zu wenige Zeichen.

Bart Simpson

Hallo!

Warum wandelst du nicht einfach ALLE Umlaute in diesen Vergleichsstring in ue, ae, oe um?
Beispiel (Pseudo-Code)

SELECT * FROM Tabelle WHERE Replace(Name, 'ü', ue) = Replace('Müller', 'ü', ue)

mfg

Original von DeveloperX

SELECT * FROM Tabelle WHERE Replace(Name, 'ü', ue) = Replace('Müller', 'ü', ue)  

Sowas in die Richtung hab ich mir auch überlegt, aber dann müsste ich die Daten quasi dupliziert in einer "Such-Spalte" speichern (was ein ziemlich hohes Datenvolumen bedeuten würde), denn ein dynamisches Replace über >40 Mio. Datensätze ist kein Spass 😉

Bart Simpson

Hm,

mal ganz naiv:

SELECT * FROM Tabelle WHERE name IN ('Müller', 'Mueller')

wobei Du Dir die IN-Klausel vorher in C# zusammenbaust?

Das ist aber im Prinzip identisch mit dem Vorschlag von Tom, nur dass er OR's nutzen würde...

Bart Simpson

Seien wir mal realistisch, es wird wohl eher wenige Namen mit mehr als 3 Umlauten geben. Daraus folgt, es gibt höchstens 8 Kombinationen. Das ringt der Datenbank auch nur ein Gähnen ab.

Die Variante mit dem IN erscheint mir aber besser als die ORs. Semantisch ist es natürlich das Gleiche, aber der Optimierer kann da doch ganz andere Sachen draus basteln.

Original von Mr. Bart Simpson
Das ist aber im Prinzip identisch mit dem Vorschlag von Tom, nur dass er OR's nutzen würde...

Hast recht. Den Beitrag hatte ich irgendwie übersehen, sorry