Überarbeitung der Suchfunktion

[noRiddle (revilonetz)]

Ich denke die Suchfunktion des Shops bedürfte ohnehin einer Verbesserung und Überarbeitung.
Das ist allerdings so eine Sache. Solange Verträge* mit Drittanbieteranbietern wie "Site Search 360 Produktsuche" bestehen, wird die Motivation an der Suchfunktion etwas zu verbessern evtl. begrenzt sein.
Allerdings kann man ja eine eigene Suche update-sicher bauen, da die Skripte die für die Suche angesporchen werden über Template-Dateien verlinkt sind.
Ideen dazu habe ich schon lange, allein, die Zeit...

Gruß,
noRiddle

* Verträge mit Drittanbieteranbietern
Zumindest gehe ich davon aus, daß es Verträge mit solchen Drittanbietern gibt die modified ein wenig Kohle in die Kasse spülen.

*NACHTRAG*
Eine verbesserte Suche könnte man gleich auch mit einer indizierten Suche verbinden (>> Index Suche für den Modified Shop).

[EDIT Tomcraft 27.02.2023: Beitrag abgetrennt von "MODUL: t10: Suchbegriffstatistik für Shopversion 2.x".]

Linkback: https://www.modified-shop.org/forum/index.php?topic=42841.0

[Timm]

Moin

Bin immer für Verbesserungen. Aber so schlecht ist unsere Suche nicht. Die autocomplete Suche kostet bei xt Commerce zb 175-350€ extra. Dafür gibts in xt Commerce aber wohl sowas wie "MODUL: t10: Suchbegriffstatistik für Shopversion 2.x" von Hause aus.

Finde den Vorschlag von @p3e gut, dass man Synonyme festlegen kann, die global gelten. Sonst müsste man alle bestehenden und neuen Artikel mit den zusätzlichen Suchwörtern ausstatten.

Vielleicht ein Featurewunsch im Bugtracker?

Gruß Timm

[EDIT Tomcraft 27.02.2023: Beitrag abgetrennt von "MODUL: t10: Suchbegriffstatistik für Shopversion 2.x".]

[voodoopupp]

Da teile ich schon seit Jahren mit p3e die Meinung, weiß aber einfach nur nicht, wie man die Suche auf komplexe Art und Weise sauber hinbekommt.

Denn im Allgemeinen sind die Suchbegriffe sinnvoll, die Suche an sich muss aber alles sauber miteinander verknüpfen können und entsprechend gewichten.

Und dann driftet man von der Funktionalität der Statistik doch arg weit weg.

Ich denke, wir sollten mal eine brachial starke Suche in modified zum Laufen bekommen, in der (fast) jeder seine Featurewünsche umgesetzt sieht bzw. diese zumindest soweit abdeckt, dass die wichtigsten Bausteine abgedeckt sind......nur ich denke, da hat am Ende doch jeder eine andere Vorstellung von, was notwendig ist und was nicht.

Aber dafür sollten wir wohl mal einen eigenen Thread aufmachen, in dem man sich austauscht und wir ein passendes Feature-Set aufbauen.

Grüße
Dominik

[EDIT Tomcraft 27.02.2023: Beitrag abgetrennt von "MODUL: t10: Suchbegriffstatistik für Shopversion 2.x".]

[noRiddle (revilonetz)]

[...]
Aber dafür sollten wir wohl mal einen eigenen Thread aufmachen, in dem man sich austauscht und wir ein passendes Feature-Set aufbauen.
[...]

Dann mach doch mal (mit Bezug auch auf diesen Thread).

Was die Verantwortlichen bei modified betrifft sage ich allerdings nochmals:

[...]
Das ist allerdings so eine Sache. Solange Verträge* mit Drittanbieteranbietern wie "Site Search 360 Produktsuche" bestehen, wird die Motivation an der Suchfunktion etwas zu verbessern evtl. begrenzt sein.
[...]

* Verträge mit Drittanbieteranbietern
Zumindest gehe ich davon aus, daß es Verträge mit solchen Drittanbietern gibt die modified ein wenig Kohle in die Kasse spülen.
[...]

Gruß,
noRiddle

[EDIT Tomcraft 27.02.2023: Beitrag abgetrennt von "MODUL: t10: Suchbegriffstatistik für Shopversion 2.x".]

[ChristianRothe]

Das Thema Suche habe ich bei mir im Shop schon ausführlich bearbeitet und Ansätze gefunden, wie ich das Finde-Verhalten der Suche erheblich verbessern konnte. Wir hatten unter anderem damit zu kämpfen, dass Redakteure in Produktbeschreibungen und Kunden bei der Suche die Schreibweise von (gesuchten) Produkten erheblich variieren.

In unserem Fall der Sporternährung sollten die Suche nach
- Energiegel
- Energygel
- Energie Gel
- Energy Gel
- Energie-Gel
- Energy-Gel
- Energiegäl
- Ennergie Gehl usw.
mehr oder weniger zu vergleichbaren Ergebnissen führen.

Dies habe ich in einem mehrstufigen Ansatz gelöst:

a) Ich habe mir eine zusätzliche Datentabelle products_searchdata  angelegt, in der ich in einer einzigen Tabelle alle relevanten Suchdaten in einem einzigen Datensatz pro Shop-Artikel zusammenfasse.

Hier liegen dann quasi "Duplikate" von products_short_description, products_description etc. - und zusätzlich auch neu zusammengestellte Daten wie die eine Aneinderreihung aller Produkt-Attribute, die mit einem Artikel verknüpft sind. Wenn ich also bei einem Artikel "Hersteller X - Energiegel" als auswählbares Produktattribut "Geschmacksrichtung" die Attributwerte "Orange", "Zitrone", "Apfel" habe, so fülle ich dann in meiner Zusatztabelle products_searchdata das Feld "products_autoattributes" mit der Zeichenkette "orange zitrone apfel". Damit kann ich also auch effizient nach Attributwerte, ohne aufwändige SQL-Joins mit den Tabellen products_attributes, products_options und products_options_values machen zu müssen.

Die Datentabelle products_searchdata erzeuge ich einmal täglich neu per Cronjob - oder aktualisiere den Datensatz jeweils für ein Produkt, wenn dieses Produkt in der Artikelverwaltung gespeichert wird.

Meine Suche durchsucht nicht mehr die eigentlichen Produktdaten, sondern nur noch die Suchtabelle  products_searchdata.

b) Die zweite Maßnahme ist eine spezielle Behandlung der Produktdaten vor der Abspeicherung in products_searchdata. Stichworte: Stemming und Phonetische Repräsentation.

Bei Stemming wird ein Wort auf seinen Wortstamm zurückgeführt. Beispiel:
Aus
- "Herren"
- "Herrn"
- "Herrs"
- "Herrens"
- "Herrns"
wird einfach "Herr". So bekommt man die unterschiedlichen Schreibweisen eines Begriffs in den Griff - sowohl in den Produktbeschreibungen wie später auch bei den Begriffen, die ein Shopbesucher in die Suche eintippt.

Für solche Stemming-Geschichten gibt es den Porter-Stemmer-Algorithmus: https://de.wikipedia.org/wiki/Porter-Stemmer-Algorithmus

Für das Stemming existieren fertige PHP-Bibliotheken wie z.B. der Snowball Stemmer. Wenn ich also meine products_short_description, products_description in der Tabelle products_searchdata abspeichere, haben sie vorher den Stemming-Prozess durchlaufen. Deshalb wird also nur noch die Grundform aller Begriffe aus einem Text gespeichert - und später auch nur noch gesucht, da ich die Suchbegriffe eines Nutzers vor der Suchabfrage ebenfalls durch den Stemmer laufen lassen.

c) Maßnahme Nummer 3 ist die phonetische Behandlung. Wörter werden in Zahlencodes überführt. Dazu benutze ich die für die Sprache Deutsch die Kölner Phonetik https://de.wikipedia.org/wiki/K%C3%B6lner_Phonetik  Ziel dieses Verfahrens ist es, gleich klingenden Wörtern denselben Code zuzuordnen, um bei Suchfunktionen eine Ähnlichkeitssuche zu implementieren. Damit ist es beispielsweise möglich, in einer Namensliste Einträge wie „Meier“ auch unter anderen Schreibweisen, wie „Maier“, „Mayer“ oder „Mayr“, zu finden. Aus "Müller-Lüdenscheidt" wird dann bei mir 6050750206802

Für die Kölner Phonetik findet man im Internet ebenfalls fertige PHP-Module, die man mit wenig Anpassungsaufwand nutzen kann.

Ich erstelle also für alle Inhalte aus Datenfeldern wie products_short_description, products_description phonetische Repräsentationen - und mache dann mit den Sucheingabe den Nutzers dasselbe. Dann suche ich also mit der phonetischen Wiedergabe des Suchbegriffs im phonetischen Datenbestand.

d) Dies bringt uns zu Punkt 3: Zur Volltextsuche.  Für meine Suchdatentabelle products_searchdata habe ich mit MySQL-Bordmitteln einen Volltextindex angelegt. Dadurch erfolgt die Suche ziemlich performt - und es erspart mir, selbst einen Suchindex erstellen zu müssen.

e) Die Daten in products_searchdata durchlaufen zusätzlich noch einige Aufbereitungsschritte, die ich bislang nicht erwähnt habe:

1) Stopwörter / Füllwörter werden weggefiltert. Dazu benutze ich die Stop-Wort-Liste und Go-Wort aus dem Modul für die automatischen Metatags: "aber, achten, alle, allein, allen, allem, allerdings, alles, als, andere, anderen, anderer, anderes, ändern, anders, angesichts, anstatt, auch, auf, aufgrund, aus, außerdem...."

2) Wörter mit Bindestrich werden zerlegt und daraus neue zusätzliche Begriffe zusammengesetzt. Beispiel Steht irgendwo in einer Produktbeschreibung "Energie-Riegel" so werden daraus gleich drei neue Begriffe, die ich dem Text hinzufüge: "Energie", "Riegel" (jeweils einzeln) und "Energieriegel".

3) Produktattributwerte wie "Geschmacksrichtung: Zitrone" sind noch mit Synonymen wie "Lemon", "Zitrus" usw. verschlagwortet, die bei der automatischen Erzeugung von Suchtexten aus den Attributen ebenfalls berücksichtigt und für den jeweiligen Artikel in der Tabelle products_searchdata mit abgespeichert werden. So erscheint dann bei einer späteren Suche nach "Lemon" auch das Zitronen-Produkt als Treffer, obwohl dieser Begriff gar nicht im Artikelnamen oder in der Artikelbeschreibung enthalten ist.

f) Für die Sortierung der gefunden Artikel habe ich mir ein Relevanz-Ranking gebastelt. Es beruht darauf, ob die Originalschreibweise der Suchbegriffe eines Nutzers auch tatsächlich in der Originalschreibweise der Artikeldaten vorkommt. Je größer diese Übereinstimmung ist, desto weiter oben erscheint ein Produkt in der Trefferliste der Suche.

Durch die phonetische Suche kommt es zum Teil durchaus zu Treffern, die man sich nicht direkt erklären kann. Aber dies ist in der Praxis nicht schlimm, solange die relevanten Treffer ganz oben in der Liste stehen. Letztlich kennt jeder Nutzer dies aus Suchmaschinen wie Google: Du erhältst 2 Millionen Treffer - schaust aber nur die ersten 10 davon an. Welcher "Unsinn" auf Seite 4 oder 27 der Trefferliste steht, ist für Dich völlig egal.

Wer meine Suche einmal ausprobieren möchte, bitteschön: https://www.ausdauerleistung.de/advanced_search_result.php?keywords=energiegel

Ich denke, dass ich meine Ziele ganz brauchbar erreicht habe:
- Für die meisten üblichen Suchanfragen in unserem werden tatsächlich Treffer anzeigt (und nicht "Kein Artikel gefunden").
- Relevante Suchergebnisse erscheinen am Anfang der Trefferliste
- Die Performance der Suche ist akzeptabel (Antwortzeiten < 1,5 sec)
- Unterschiedliche (oder gar falsche) Schreibweisen von Suchbegriffen führen trotzdem zu ähnlichen / brauchbaren Ergebnissen
- Für die Shop-Admins entsteht kein Zusatzaufwand  für das manuelle Hinzufügen zusätzlicher Suchbegriffe. Der Shop erledigt dies automatisch.

An der Umsetzung des skizzierten Konzepts habe ich etwa zwei Wochen gewerkelt. Ich denke, dass dies für das erzielte Resultat ein recht vertretbarer Aufwand war.

[EDIT Tomcraft 27.02.2023: Beitrag abgetrennt von "MODUL: t10: Suchbegriffstatistik für Shopversion 2.x".]

[Timm]

Wow. Danke für den ausführlichen Bericht.

Es gibt auf jeden Fall ziemlich gute Ergebnisse, trotz falscher Schreibweise.

ZB Lammon statt Lemon

Mir ist nur aufgefallen, dass er bei fehlendem Buchstaben zb Taubenzucker statt Traubenzucker zwar in der Box oben mit der autocomplete Suche etwas anzeigt, wenn man dann auf die Lupe klickt es allerdings ein leeres Ergebnis gibt.

Wärst du denn bereit deine Arbeit dem modified Team oder der Community zur Verfügung zu stellen?

Grüße Timm

[EDIT Tomcraft 27.02.2023: Beitrag abgetrennt von "MODUL: t10: Suchbegriffstatistik für Shopversion 2.x".]

[ChristianRothe]

Hallo Timm, bei Dir muss ich mich ganz herzlich bedanken! Deine Suche nach "taubenzucker" hat mich darauf gebracht, dass die Fuzzy-Suche nicht als Backup anspringt, wenn die "normale" phonetische Suche keine Ergebnisse bringt. Denn die Fuzzy-Suche ist quasi als "Notnagel" auch vorgesehen - aber eben nur dann, wenn die phonetische Suche zu keinem Treffer führt. Dann wird zusätzlich noch als zweiter Suchschritt die Fuzzy-Suche ausgeführt, um zu Ergebnissen zu kommen. Dies habe habe ich jetzt wieder aktiviert. Nun bringt auch die Suche nach "Taubenzucker" oder "Raupenzucker" ein sinnvolles Ergebnis.

Was die Zurverfügungstellung von Programm-Code angeht: Wäre grundsätzlich machbar. Aber.... mein Shop ist ein sehr stark modifiziertes Software-Produkt - insbesondere, was den Aufbau von Produktlisten in Kategorien und bei Suchergebnissen angeht. Deshalb ist mein Code nicht Copy-&-Paste kompatibel zum Modified Shop. Hier bräuchte es größere Anpassungen. Was ich aber zur Verfügung stellen könnte, wäre der Code, welcher das Stemming und die Erzeugung der phonetischen Wortrepräsentationen erledigt.

[EDIT Tomcraft 27.02.2023: Beitrag abgetrennt von "MODUL: t10: Suchbegriffstatistik für Shopversion 2.x".]

[Timm]

Moin

Danke, dass du es oder Teile davon zur Verfügung stellen würdest.

Könntest du etwas zur Größe der DB Tabelle sagen? Was so der Grundstamm ist und wie sich das mit der Anzahl der Artikel entwickelt.

Wenn es für alle funktionieren soll, dann wären mehrere Gigabyte große Tabellen ja ein Ausschlusskriterium. Es müsste für einen Shop mit 50 Artikeln und Webhosting genauso funktionieren wie bei einem mit 100.000 Artikeln und eigenem Server.

Wirkt sich das sonst auf die Geschwindigkeit des Shoos aus?

Gruß Timm

[EDIT Tomcraft 27.02.2023: Beitrag abgetrennt von "MODUL: t10: Suchbegriffstatistik für Shopversion 2.x".]

[ChristianRothe]

Die Datentabelle wird nicht größer als die Tabelle products_description. Wenn in einem Shop die Tabelle products_description nicht platzt, dann platzt meine Zusatztabelle products_searchdata auch nicht.

Gucken wir uns ein Beispiel an: Wenn ich Deinen vorhergehenden Beitrag durch den Stemmer jage, bleibt dies davon übrig:

"moin dank du es teil davon verfügung stell würdest könntest größe db tabell sag so grundstamm anzahl artikel entwickelt für funktioni dann wären mehr gigabyt groß ausschlusskriterium müsste shop 50 artikeln webhosting genauso 100.000 eig serv wirkt geschwind shoos gruß timm"

Und die phonetische Umsetzung davon lautet:

"606 2064 20 08 205 20306 30734064 8205 372082 4062082 470 21 20105 804 80 47068206 06805 0720405 062304052 37 30642060 206 30706 607 4040102 0850847020706 6820 801 Y5Y0 07204056 301082064 406080 Y1Y0Y0YAY0Y0Y0 04 8073 30742 4083062 808"

Wie man sieht, hat die Textmenge / Datenmenge gegenüber dem Ausgangstext von Dir abgenommen.

Bei uns im Shop sind aktuell ca. 4.000 Artikel in der Datenbank drin. Wie performant die Suche mit 100.000 Artikeln laufen würde, kann ich nicht sagen. Da aber bei der Suche die "serienmäßige" Volltextindex-Funktion der MySQL-Datenbank benutzt wird ("... MATCH (tabellenspalte_1, tabellenspalte_2, tabellenspalte_3) AGAINST(Suchwort_1 Suchwort_2)"), würde ich auch noch akzeptable Antwortzeiten erwarten.

[EDIT Tomcraft 27.02.2023: Beitrag abgetrennt von "MODUL: t10: Suchbegriffstatistik für Shopversion 2.x".]

[noRiddle (revilonetz)]

Ein sehr interessanter Ansatz.
Wie fängst du ab, daß die Suchergebnisse zu indifferent werden ?
Auf vielen Online-Shops sind Suchergebnisse richtig bescheiden, es wird zu viel Nicht-Zutreffendes angezeigt.
Man weiß dann nie, ob das ein (Verblödungs-)Trick sein soll, um mehr Kaufreize zu generieren, indem man einfach auch Artikel anzeigt die nicht zur Suche passen, oder ob Algorithmen verwendet wurden die die Ergebnisse zu indifferent machen.
KI gibt es ja nicht, das sind immer logische Vorgänge und hinterlegte Bibliotheken an Daten.

Ein Beispiel was so passieren kann ist was Tim hier erklärt: Ticket #2311
wenn auch es andere Ursachen hat.

"Energiegäl" und "Ennergie Gehl"
ist auch nicht schlecht. Man muß wohl inzwischen der Pisa-Studie gerecht werden.

Gruß,
noRiddle

[EDIT Tomcraft 27.02.2023: Beitrag abgetrennt von "MODUL: t10: Suchbegriffstatistik für Shopversion 2.x".]

[ChristianRothe]

Zu viele Treffer sind meines Erachtens kein Problem, sofern sich am Beginn der Trefferliste relevante Ergebnisse befinden.

Ich mache bei meiner Suche auch eine Relevanzbeurteilung in folgendem Stil (vereinfachter Auszug aus meinem Programmcode):

Code: PHP  [Auswählen]

$select_str = "(0";
for ($i = 0, $n = $_keyword_count;  $i < $n; $i ++) {
        $keyword = $keywords[$i];
        // Keyword als String im Produktnamen enthalten?
        $select_str .= "+(5*(INSTR(LOWER(pd.products_name), LOWER('".$keyword."')) > 0))";
        // Keyword als String in Kurzbeschreibung enthalten?
        $select_str .= "+(3*(INSTR(LOWER(pd.products_short_description), LOWER('".$keyword."')) > 0))";
        // Keyword als String in Artikelbeschreibung enthalten?
        $select_str .= "+(2*(INSTR(LOWER(pd.products_description), LOWER('".$keyword."')) > 0))";
}
$select_str .=    ") as relevance_score";

Auf Deutsch übersetzt: Ist ein Suchwort im Artikelnamen enthalten, gibt es fünf Punkte. Taucht das Suchwort in der Kurzbeschreibung auf, bringt dies 3 Punkte. Ein in der Artikelbeschreibung enthaltenes Suchwort bringt 2 Punkt. Die Summe ergibt dann die Gesamtrelevanz relevance_score.

Je genauer die Produktdaten zu den Suchbegriffen passen, desto höher fällt der Relevanz-Wert aus. Meine Trefferliste ist nach diesen Wert absteigend sortiert. Natürlich kann man hierbei in der SQL-Abfrage auch einen Minimumwert verwenden "where relevance_score > SCHWELLWERT" Durch eine entsprechende Wahl von SCHWELLWERT kann man die Trefferliste verlängern oder verkürzen und wenig relevante Treffer wegfiltern.

Natürlich kann das Ranking auch durch die Wahl anderer Punktwerte als 5, 3 und 2 beliebig getuned werden. Das Feintuning meines Relevanzrankings bleibt natürlich unser Geschäftsgeheimnis. 

Bei dem Beispiel mit "grun" und "im Grunde" (vgl Ticket #2311) hilft eine Abprüfung, ob ein Keyword als Ganzes im Text enthalten ist. Wird nach "grün" bzw. "grun" gesucht, würde ein "grün" im Text mehr Relevanzpunkte bringen, als wenn dort nur "im Grunde" steht.

Code: PHP  [Auswählen]

        // Keyword als komplettes Wort im Produktnamen enthalten?
        $select_str .= "+(3*(INSTR(CONCAT(' ',pd.products_name,' '), ' ". $keyword." ') > 0))";

[EDIT Tomcraft 27.02.2023: Beitrag abgetrennt von "MODUL: t10: Suchbegriffstatistik für Shopversion 2.x".]

[noRiddle (revilonetz)]

Verstehe, wobei dein Beispiel voraussetzt, daß du seo-technisch gut gearbeitet hast (Keywords in Produkt-Name, Kurz- und Langbeschreibung (was ist mit products_keywords*¹   ?), denn ansonsten dürfte die Relevanz überall ziemlich gleich sein.

Die Gewichtung ob Volltreffer, also Keyword als ganzes Wort vorhanden, oder Teiltreffer, also Keyword als Teil eines Wortes vorhanden, ist allerdings sehr gut.*² Das ist etwas was imo ohnehin in den Core einfießen sollte.

Hebt die komplexere Konditionierung bei der Suche (wegen der Relevanz oder Voll- und Teil-String) den Vorteil der Extra-Tabelle nicht wieder ein wenig auf ?
Dabei muß noch beachtet werden ob MySQL OR-Conditions abkürzt ("short-circuit").
Bei einer Query wie

Code: SQL  [Auswählen]

SELECT * FROM orders
WHERE orders_id = 1 OR orders_id = 2 OR orders_id = 3);

geschieht kein short-circuit und es werden alle drei Records zurückgegeben,
wohingegen bei so etwas

Code: SQL  [Auswählen]

SELECT * FROM orders
WHERE TRUE OR (SELECT orders_id FROM orders);

SELECT * FROM orders
WHERE FALSE OR (SELECT orders_id FROM orders);

SELECT * FROM orders
WHERE TRUE OR orders_id = 3;

SELECT * FROM orders
WHERE FALSE OR orders_id = 3;

bei der ersten Query offensichtlich short-circuit angewandt wird, denn es gibt keinen Error, während bei der zweiten Query dieser Error ausgegeben wird:
#1242 - Unterabfrage lieferte mehr als einen Datensatz zurück
Die dritte Query gibt alle Orders aus und die vierte nur die mit orders_id 3.

Quelle der Idee herauszufinden ob MySQL short-circuits kennt bei OR-Clauses: MySQL Short Circuit WHERE

Anders gesagt:
Führt MySQL wirklich immer alle OR-Clauses durch wenn bereits die erste Condition einen Treffer landet ?
(wobei noch dazu kommt, daß das DBMS intern aus Optimierungsgründen die Reihenfolge der Conditions neu bestimmen kann.)
Ist der oben geführte Beweis, daß es short-circuits geben kann nicht aussagekräftig, weil die erste Condition einen Boolean forciert ?

Will sagen. Wie hast du deine $select_str .= ...  as relevance_score  logisch verknüpft ?

Oder:
Hast du es auch mal mit Boolean Full-Text Searches versucht ?

Ich weiß, viel Neugierde, aber hast du mal Benchmark-Tests zur Geschwindigkeit gemacht (mit SQL_NO_CACHE) ?
Zumal es nach im I-Net gefundenen Benchmarks auch wichtig sein kann ob man LIKE oder INSTR benutzt.

Vielleicht sollte man die Diskussion über die Suchfunktion aus dem vorliegenden Thread in einen neuen überführen, denn das führt hier weit über das vorliegende Modul hinaus.

Gruß,
noRiddle

*¹  products_keywords
oder funktioniert die Anwendung von "Kölner Phonetik" so gut, daß es der zusätzlichen Suchworte nicht mehr bedarf ?

*² Gewichtung
Die Gewichtung ob Volltreffer oder nur Teil-String müsste imo an erster Stelle stehen, vor deiner Gewichtung nach Treffer in Produkt-Name, Kurz- und/oder Langbeschreibung.

Daneben wäre es noch eine Diskussion wert, ob man eingegebene Suchworte zwingend am Leerzeichen trennen soll, denn die meisten User dürften die Möglichkeit Suchwort-Kombis in doppelte Anführungsstriche zu setzen nicht kennen (nicht die Hilfe gelesen haben).

[EDIT Tomcraft 27.02.2023: Beitrag abgetrennt von "MODUL: t10: Suchbegriffstatistik für Shopversion 2.x".]

[ChristianRothe]

Ich berücksichtige bei meinen Relevanz-Ranking noch viel mehr Spalten also nur die paar genannten. Wollte ich hier aber nicht allzu breit auswalzen, um nicht vor lauter Details den Blick aufs Wesentliche zu verstellen.

Der relevance_score ist eine Integer-Zahl, die mit dem Finden der Suchtreffer absolut nix zu tun. Die Treffer werden bei mir - wie schon ein paar Beiträge vorher geschrieben - mit einer MySQL Boolean Volltext-Suche gefunden (...MATCH(...) AGAINST(...)). Der Relevance Score dient nur der Bewertung der Treffer. Hier werden einfach Zahlen addiert:

$select_str .= "+( 2 * (INSTR(LOWER(pd.products_description), LOWER('".$keyword."')) > 0))";

Der fettgedruckte Ausdruck wird entweder 0 oder 1. Mit dem Multiplikator 2 vorne erhalte ich also entweder den Wert 0 oder 2 - je nachdem, ob das Keyword in der untersuchten Spalte (hier: products_description) enthalten ist. In je mehr Spalten das Keyword vorkommt,  desto höher der Relevance Score. Welche Spalten hierbei untersucht und berücksichtigt werden, hängt nur von der Kreativität der Entwickler ab.

Da ich die MySQL-Volltextsuche benutze, ist die Performance der Suche mehr als ordentlich. Als Admin in meinem Shop lasse ich alle Queries ungechached laufen. Auch da ist die Performance in Anbetracht der Leistungsfähigkeit der Suche immer noch recht gut. Dafür sorgt eben die MySQL Boolean Volltext-Suche.

[EDIT Tomcraft 27.02.2023: Beitrag abgetrennt von "MODUL: t10: Suchbegriffstatistik für Shopversion 2.x".]

[noRiddle (revilonetz)]

Aha, hatte ich wohl übersehen.

Meine Frage

[...]
Oder:
Hast du es auch mal mit Boolean Full-Text Searches versucht ?
[..]

hat sich damit ja beantwortet.

MATCH AGAINST hat den kleinen Nachteil, daß du erst ab 4 Zeichen suchen kannst, nicht bereits bei 3, aber was soll's.
Auch hier bleibt allerdings die Frage wie du die MATCH AGAINST logisch verbindest, denn wenn mit OR könnte man,
da es wahrscheinlich keinen short-circuit geben wird, sich den Relevance Score evtl. sparen, indem man CASE oder IF verwendet um die Query nach Treffer abzubrechen.
Das dürfte nochmals einen Geschwindigkeitsvorteil bringen.
Oder irre ich ?

Gruß,
noRiddle

*NACHTRAG*
Verwendest du deine Vorgehensweise auch für eine/die Autocomplete-Suche ?

[EDIT Tomcraft 27.02.2023: Beitrag abgetrennt von "MODUL: t10: Suchbegriffstatistik für Shopversion 2.x".]

[ChristianRothe]

Den Relevance Score sollte man sich meines Erachtens nicht sparen. Die Anzeigereihenfolge der Suchergebnisse soll schließlich nicht nach dem Zufallsprinzip erfolgen. Mit "order by relevance_score desc" sorge ich dafür, dass relevante Ergebnisse vorne stehen. Wenn ich meine Suche diesbezüglich anhand von echten Suchanfragen realer Kunden überprüfe, scheint dies recht gut zu klappen. An der Spitze der Trefferliste stehen in der Regel Produkte, die ich als Kundenberater aus Fleisch und Blut auch herausgesucht hätte, wenn man mir in einem Gespräch die Suchbegriffe als Stichworte genannt hätte.

[EDIT Tomcraft 27.02.2023: Beitrag abgetrennt von "MODUL: t10: Suchbegriffstatistik für Shopversion 2.x".]