Database query mit/ohne Umlaute

  • Hallo zusammen,


    ich habe eine sqlite datenbank mit ortschaften. ich möchte diese durchsuchen, das heisst ich möchte nach "Munchen" suchen und er soll dann "München" finden...
    ich komm nicht mehr weiter, umgekehrt habe ich eine Lösung gefunden aber das hilft mir nicht. wie würdet ihr dieses problem angehen? kann mir bitte jemand eine richtung zur lösung aufzeigen?


    Danke

  • Hi,
    Wie wäre es wenn die Datenbank keine Umlaute enthalten und bei der Sucheingabe auch alle Umlaute entfernt werden?

    MfG,
    Christopher


    Eine gewisses Maß an Freundlichkeit kann man auch von Menschen im Internet erwarten.
    Das Forum basiert komplett auf der Freiwilligkeit ihrer Nutzer und diese sollen sich wohlfühlen! Daher seid bitte freundlich. Danke

  • Hi,
    Wie wäre es wenn die Datenbank keine Umlaute enthalten und bei der Sucheingabe auch alle Umlaute entfernt werden?


    Dagegen spricht vermutlich, dass die Inhalte aus der Datenbank auch dargestellt werden müssen. Und da sieht 'Munchen' einfach mal scheiße aus. ;)


    Leider fällt mir gerade keine andere Möglichkeit ein, als potenzielle Umlaute zu ersetzen.
    Wenn also jemand nach 'Oberhausen' sucht, müssten folgende Schreibweisen berücksichtigt werden:
    Oberhausen
    Oberhäusen
    Öberhausen
    Oberhaüsen
    Öberhäusen
    Oberhäüsen
    Öberhaüsen
    Öberhäüsen


    Mir erscheint das nicht sinnvoll.
    Warum die Leute nicht nach den jeweiligen Umlauten suchen lassen?
    Warum nicht nach Relevanz Suchvorschläge in einer Liste anzeigen?
    'M' -> München, Moers, Mannheim...
    'Ma' -> Magdeburg, Mannheim, Mainz...
    'Mar' -> Marburg, Marienthal...


    Ansonsten wird das sicherlich nur mit Ersetzung der Teilstrings funktionieren.

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Daraus folgt: je mehr Käse, desto weniger Käse.


    »Dies ist ein Forum. Schreibt Eure Fragen in das Forum, nicht per PN!«

  • Muenchen und Duesseldorf sind ziemlich sinnlose Schreibweisen, danach sucht doch niemand.


    Ich habe einige Implementierungen des OnScreenKeyboards gesehen, welche die Umlaute nicht direkt verfügbar machen.
    Viele Menschen haben aber keinen Bock ne gefühlte halbe Minute lang auf 'u' zu tippen bis 'ü' kommt sondern verlassen sich auf die Vorschläge der Autokorrektur.
    Es wäre nur sinnvoll, bei der Suche entsprechende Nutzungsgepflogenheiten der User zu berücksichtigen.

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Daraus folgt: je mehr Käse, desto weniger Käse.


    »Dies ist ein Forum. Schreibt Eure Fragen in das Forum, nicht per PN!«

  • aber munchen und dusseldorf sucht jemand?


    wie bereits gesagt entweder benutzt man öäü oder oe ae ue, alles andere wäre schwachsinn und noch unintuitiver als oe ae ue


    das mit den auto vorschlägen is ne gute idee und sollte auch so gemacht werden

  • aber munchen und dusseldorf sucht jemand?


    Ja.
    Einfach aus dem Grund, dass man für 'Munchen' 7 Tasten und damit ungefähr 4 Sekunden Tippzeit braucht, während 'München' auf Grund des Umlautes die Tippzeit auf ungefähr 12 Sekunden hoch treibt.
    Wer Informationen sucht, der will nicht warten.

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Daraus folgt: je mehr Käse, desto weniger Käse.


    »Dies ist ein Forum. Schreibt Eure Fragen in das Forum, nicht per PN!«

  • Vielen Dank für die zahlreichen Antworten! Ich sehe, es ist nicht so trivial wie ich es zuerst dachte.
    Das mit er Autokorrektur hat mich auf eine Idee gebracht, ich versuch das mal zu implementieren. Ich halte euch auf dem Laufenden!


  • Ja.
    Einfach aus dem Grund, dass man für 'Munchen' 7 Tasten und damit ungefähr 4 Sekunden Tippzeit braucht, während 'München' auf Grund des Umlautes die Tippzeit auf ungefähr 12 Sekunden hoch treibt.
    Wer Informationen sucht, der will nicht warten.


    Es geht nicht drum was mehr Zeit kostet sondern ob normale User intuitiv nach Munchen statt Muenchen oder München suchen würden.
    Das würde ich einfach mal ohne Benutzerstudie verneinen.


  • Es geht nicht drum was mehr Zeit kostet sondern ob normale User intuitiv nach Munchen statt Muenchen oder München suchen würden.
    Das würde ich einfach mal ohne Benutzerstudie verneinen.


    Und ich würde es bejahen, da ich es tue.

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Daraus folgt: je mehr Käse, desto weniger Käse.


    »Dies ist ein Forum. Schreibt Eure Fragen in das Forum, nicht per PN!«

  • Und dann weint der Durchschnittsuser ob dieser unglaublichen Unsicherheit und des NSA Skandals.


    Aber stimmt schon, vermutlich bin ich nicht der Durchschnittsuser. Ich besitze gar kein WhatsApp.

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Daraus folgt: je mehr Käse, desto weniger Käse.


    »Dies ist ein Forum. Schreibt Eure Fragen in das Forum, nicht per PN!«

  • um wieder zurück zum Thema zu kommen.....



    weiß grad nicht, ob es auch für SQLite gilt, aber in MySQL kann man sowas durch das Charset steuern. Es gibt Charsets, bei denen ein ü und ein u dasselbe ist. Wenn ich also nach "Munchen" suche, würde sowohl "München" als auch "Munchen" zurück geliefert werden können.


    Evtl. hilft das ja beim weiteren googeln ...



    soweit ich weiss unterstützt sqlite leider nur UTF8 und UTF16 :(


    ich habe bis jetzt noch keine schöne Lösung gefunden, also werde ich es vorübergehend mit einer String replace Methode machen, diese funktioniert gut genug für den Moment

  • Die Datenbank ist deine eigene, also du pflegst die Daten selbst ein?
    dann würde ich eine Spalte SUCHNAME ergänzen und dort den Ortsnamen "suchfreundlich" speichern, etwa "München" -> MUNCHEN.


    Die gleiche Umwandlung verwendest du in der App dann auch für die Eingabe des Users et voila, sowohl Munchen als auch München werden gefunden.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!