Volltextindex vs. Index

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Volltextindex vs. Index

    Frage,

    mal angenommen ich hab eine Profil Tabelle in der folgenden Daten eines Users gespeichert sind:

    - Name
    - Vorname
    - Email
    - Ort
    - Strasse
    - PLZ
    - Homepage
    - ...

    Die Liste könnte noch weiter gehen. Eine Suche über alle Felder soll möglich sein! Natürlich wäre es jetzt quatsch auf alle Felder mit einem OR Operator zu suchen zumal MySQL nur eine Index pro Query benutzt und ja mehr oder weniger selber entscheidet welchen er nimmt.

    Voraussetzung: Die Daten existieren in den verschiedensten Sprachen und in den Tabellen wird UTF-8 benutzt.

    Was ist jetzt die performantere Lösung angesichts steigender Profil Datensätze:

    - Eine neue Spalte in der gleichen Tabelle in der alle Daten leerzeichen getrennt dupliziert werden und darauf ein Volltext Index zu legen. Da gibt glaub ich Probleme mit nicht gleichen Zeichensätzen!?

    oder

    - Eine 2 Tabelle nur zum Suchen in der es 2 Spalten gibt, die ID zum Datensatz in der eigentlichen Profil Tabelle als Referenz und 1 Spalte wo für einen Datensatz aus der Profil Tabelle jeder Wert eingefügt wird. Darauf einen Index und fertig. Ach ja, die Abfrage sehen dann aber auch anders aus von Wegen JOIN, evtl. Subselect. Ist ja auch ein Performance Kriterium!

    Vollindex oder Suchtabelle? dat is hier die Frage

    (ähm evtl. ist das hier auch besser im Brainstorming aufgehoben?!)

    f*
    Zuletzt geändert von frank7l7; 31.07.2007, 11:57.

  • #2
    Re: Volltextindex vs. Index

    Original geschrieben von frank7l7
    Voraussetzung: Die Daten existieren in den verschiedensten Sprachen und in den Tabellen wird UTF-8 benutzt.
    [...]
    - Eine neue Spalte in der gleichen Tabelle in der alle Daten leerzeichen getrennt dupliziert werden und darauf ein Volltext Index zu legen. Da gibt glaub ich Probleme mit nicht gleichen Zeichensätzen!?
    Wenn die Daten durchgängig UTF8 sind ist doch kein Problem da?!


    Generell Suchtabelle, weil man ansonsten spontan die Haupt-Tabelle in ihrer Größe verdoppelt.
    Alternativ kannst du dir auch lucene anschauen http://lucene.apache.org/ ist allerdings dann java

    Ein netter Guide zum übersichtlichen Schreiben von PHP/MySQL-Code!

    bei Klammersetzung bevorzuge ich jedoch die JavaCoding-Standards
    Wie man Fragen richtig stellt

    Kommentar


    • #3
      hmm, stellt sich nur noch die frage wie dann der index sortiert wird bei einer UTF-8 Spalte. Nur zur Verständis wenn ich alle Sprachen in einer Spalte unterbringen, chinesisch, russich, englisch, ... wie wird der index dann sortiert? Der Index wird ja nachdem B-Tree Prinzip mit Schlüssel / Wert paar angelegt, aber die Sortierung? Wenn ich alle sprachen bunt gemischt habe dauert doch die die Suche im Index auch länger. Wäre es dann nicht besser für jede Sprache eine eigene Tabelle zu machen?

      Oder halt, der Index ist doch dann auch UTF-8, läuft die Suche auf dem Index dann eigentlich Binär? Dann wäre es ja auch egal.

      Hm, noch etwas schwer zu greifen die Sache ....

      Kommentar


      • #4
        Du solltest dich fragen: Willst du immer alle Sprachen durchsuchen?
        Wenn ich nach Bar suche im deutschen, will ich mit Sicherheit nicht nach bar im Englischen suchen.
        D.h. du müsstest die Spalten trennen.

        Was das ganze mit der Sortierung zu tun haben soll verstehe ich nicht und dass eine Volltextsuche als binärer Baum realisiert werden sollte, wage ich zu bezweifeln (auch wenn ich es nicht weiß).
        Zuletzt geändert von ghostgambler; 03.08.2007, 14:55.

        Ein netter Guide zum übersichtlichen Schreiben von PHP/MySQL-Code!

        bei Klammersetzung bevorzuge ich jedoch die JavaCoding-Standards
        Wie man Fragen richtig stellt

        Kommentar


        • #5
          Vielleicht habe ich dich nur falsch verstanden, aber ich komme partout nicht hinter dein Problem. Du hast bisher eine Tabelle mit x Spalten. Alles UTF-8. Darin liegen y Datensätze in verschiedenen Sprachen (Userprofile von Chinesen, Deutschen, etc.). Da man in MySQL aber nicht datensatzweise ein Charset angeben kann, sind alle Datensätze in UTF-8.

          Konkatenierst du nun die Spalten zur neuen Spalte x+1 (die natürlich auch UTF-8 ist), gibt es doch nur ein Problem beim Sortieren. Aber du willst ja gar nicht sortieren. Nur suchen.

          Suchen ist immer gleich: Du hast einen UFT-8 kodierten String "abc" und MySQL soll dir alle Datensätze liefern, bei denen die Spalte x+1 LIKE '%abc%' ist.

          Sollte es im Chinesischen Buchstaben geben, die dem "abc" entsprechen, sind sie in der UTF-8-Tabelle wo ganz anders als die ASCII-Zeichen.

          Ghostgamblers Einwand ist allerdings nicht von der Hand zu weisen. Eine der x Spalten wird aber sicherlich enthalten, in welcher Sprache der User spricht. Wenn du möchtest, kannst du das ja berücksichtigen wenn ein deutscher User nach "bar" sucht.
          Zuletzt geändert von onemorenerd; 31.07.2007, 15:48.

          Kommentar


          • #6
            okay ich hab mich an gewissen Stellen etwas undeutlich ausgedrückt. mir ist auf jedenfall einiges klarer geworden, die suchwörter kommen einfach in eine eigenen Suchtabelle für jede Sprache getrennt. eine Index drauf un gut ist ...

            fra*

            Kommentar

            Lädt...
            X