Wordmatch und Wordlist-Table: Nutzen?

[senloel]

Hallo,

mir ist gerade eine eher allgemeinere Frage in den Sinn gekommen, als ich ein SQL-Backup erstellt habe:
Die Wordlist bzw. Wordmatch-Tabellen sind im Vergleich sehr groß, warum benutzt man diese überhaupt?
Wäre es nicht einfacher, bei der Suche einfach auf die Images-Table zuzugreifen?

Die Gründe dafür würden mich sehr interessieren, schließlich muss ein Gedankengang dahinter sein.

Grüße,
Patrick

[Rembrandt]

Hi!

Bei einen großen Backup würde ich die Word -match und -list Tabellen nicht mit sichern, eben aus deinen genannten gründen, sie können sehr groß sein.
Besser ist es wenn das Backup wiederhergestellt ist, die Word -match und -list Tabellen mittels der rebuild_searchindex.php wiederherzustellen.

Zu dem nutzen der beiden Tabellen, es ist rein die Geschwindigkeit, bei einer Suchanfrage ist es sicher einfacher und schneller nur eine Tabelle abfragen zu müssen.
Der Suchbegriff könnte sich ja in der categories, images, oder auch in der comments Tabelle befinden.
Wenn du jetzt einige 1000ende Bilder hast, Bildbeschreibungen und  X- Kategorien, könnte ein Suchbegriff Dutzende male vorkommen.
Bis SQL die alle beisammen hast kann schon mal eine Zeit vergehen, in der Wordlist Tabelle hingegen steht jeder Suchbegriff mit einer ID nur ein einziges mal drinnen.
Wird bei einer Suchabfrage ein Treffer in der Wordlist Tabelle erzielt, steht in der Wordmatch Tabelle das Ergebnis wo der Suchbegriff überall zu finden ist, schon drinnen.

mfg Andi

[senloel]

Hallo Andi,

danke für die Erklärung!
Das würde aber im Umkehrschluss bedeuten, dass es einfach wäre, direkt in der Images-Table zu suchen, wenn man nicht nach Kommentaren und Kategorien suchen lassen will, oder?
Mir scheint die search.php ziemlich kompliziert aufgebaut zu sein 

Grüße,
Patrick

[Rembrandt]

Nein warum, auch die Images Tabelle kann einen Suchbegriff 1000ende male drinnen stehen haben, die dann von SQL alle gesucht werden müssen.

[senloel]

Okay vielen Dank!

Was ganz interessant ist: Ich habe eine eigene Suche, die in einem Unterverzeichnis liegt. 4images braucht deutlich länger, diese Seite zu laden, als wenn sie im Root-Ordner liegt.
Die Suche benutzt keine Wordmatch-Table, was aber meiner Meinung nach dennoch nicht für die längere Ladezeit verantwortlich ist.

[senloel]

Was ganz interessant ist: Ich habe eine eigene Suche, die in einem Unterverzeichnis liegt. 4images braucht deutlich länger, diese Seite zu laden, als wenn sie im Root-Ordner liegt.

By the way, hat jemand eine Idee, woran das liegen könnte?

[Rembrandt]

Du könntest in der includes/constants.php ganz unten unter "Debug contants"
die beiden aktivieren.

   
// define("PRINT_STATS", 1);
// define("PRINT_QUERIES", 1);

Auf der Webseite siehst du dann ganz unten, wie lange die SQL Abfragen gedauert haben und welche Querys bemüht worden sind, vielleicht hilfts dir weiter.

[senloel]

Hab ich gleich mal gemacht:

Page generated in 0.148177 seconds with 21 queries, spending 0.021000 seconds doing MySQL queries and 0.127177 doing PHP things. GZIP compression disabled

Sollte ja eigentlich schnell sein, die Seite lädt trotzdem länger (der Ladebalken dreht sich eine längere Zeit, bis die Seite angezeigt wird).
Lege ich die Seite in den Root-Ordner, lädt sie um einiges schneller.

Sehr komisch das ganze. Könnte es sein, dass der Aufruf von Datein verzeichnisübergreifend (sprich includes sind in einem übergeordneten Verzeichnis) länger dauert?

[Rembrandt]

Hm,.. hier habe ich etwas dazu gefunden

[senloel]

Danke für den Link!

Hab dazu mal nochmal den Code genauer unter die Lupe genommen:
Es sind gar nicht die Includes an sich, die die Seite länger laden lassen, sondern folgende Zeile:

$site_template->print_template($site_template->parse_template($main_template)); 

Nur wenn das Template ins Spiel kommt, macht das Unterverzeichnis Probleme, hm.