Überarbeitung der Suchfunktion

[voodoopupp]

[...]
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).
[...]

Also aufgrund Christans Ausführungen hier steht ja meines Erachtens schon ein sehr gutes Feature Set hier im Thread und bedarf eigentlich kaum einer weiteren Ausführung.

Ziemlich genau so würde auch ich mir eine gute Shop Suche vorstellen - hier mal kurz zusammengefasst:

• Index Suche über eine Suchtabelle, damit nicht live gesucht werden muss
  -> diese sollte sich über einen Cronjob befüllen lassen.
• Listung der Suchbegriffe nach entsprechenden Relevanz-Kriterien & entsprechend berechnetem Score: z.B.
  - Suchtreffer im Titel höhere Gewichtung als in der Produktbeschreibung
  - Treffer in Titel, Artikelbeschreibung & Artikeleigenschaften werden addiert - höhere Relevanz als "nur" im Titel
• Suche in Artikeleigenschaften/Artikelmerkmalen
• Phonetische Suche/ Fehlertolerante Suche mit Einstellung der "Schärfe/Unschärfe"
  --- zusätzliche Funktion für Deaktivierung für Unscharfe Suche, sobald "X" echte Treffer
• Stemming - Wortstamm Funktion: Wörter auf einen gemeinsamen Wortstamm zurückführen
• Suche sowohl in Umlauten & ss/ß
  sollten beide gleich ausgeliefert werden: Hoergeraet/Hörgerät - Fussball/Fußball etc.
• Suche nach ähnlichen Wörtern/Synonymen (Zitrone, Citrus, Zitrusfrucht...)
• "Schlagwortwolken", sprich Gruppierungen von unterschiedlichsten Wörtern, z.B. lustig/ausgefallen/originell/kreativ/spektakulär/spaßig
  ---> wenn also "lustig" gesucht wird, und Artikel A einen Treffer z.B. in der Artikelbeschreibung hat, soll auch Artikel B augeliefert werden, obwohl dieser nur "originell" im Text hat
• Möglichkeit direkte Landinpages festzulegen:
  bestimmten Suchbegriff direkt auf eine Seite umleiten - z.B. Suche nach "Lieferzeiten/Lieferzeit" mit direkter Umleitung auf Content-Seite "Lieferzeiten"
• Anzeige von Kategorien im Dropdown / Suche in Kategorien
  weitere Suchbegriffe für Kategorien - z.B. Kategorie "Unterhose" auch anzeigen, wenn nach "Boxershorts" gesucht wird
• Autocomplete - Möglichkeit für Suchbegriffe statt Produkte *****
  ähnlich google/amazon etc. - es wird kein Dropdown mit einzelnen Produkten angezeigt, sondern eine mit passenden Suchbegriffen. Der wichtigste Suchbegriff steht dabei ganz oben

Sicherlich ist die Liste nicht vollständig, aber das ist auch sicher immer etwas abhängig vom jeweiligen Shop/Shopbetreiber

Wenn dann die Relevanzen etc. noch im Backend einstellbar sind, dann könnte man das schon gut verwalten und shopspezifisch zusammenschalten.

***** Beispiel für Suchbegriffe Dropdown:
[ Für Gäste sind keine Dateianhänge sichtbar ]

Schwierigere Dinge/Fragen wären z.B. wie man solche Probleme löst:
- z.B. Suche nach "Eis" - wie versteht das System, dass "Eisformen, Eiswürfelbehälter, Eiskratzer, Eiscreme, Eismaschine, Stieleis" höher gewichtet werden sollen als "Reiswaffel, Reisetasche, weiss, ..."
- wie ordnet man Wortwolken bzw. Synonyme einfach und dauerhaft an Artikel bzw. wie bekommt man diese einfach auch an "neue Artikel" (siehe dazu auch den entsprechenden Beitrag von p3e)

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.

Auch ich sehe das eher weniger kritisch: besser es kommen statt 10 genau passender Treffer, lieber noch 20 weitere weniger gut passende Artikel - denn wenn der Kunde 5 mal die Suche anwirft und immer nur 2 passende Treffer erhält, ist er schneller weg als man bis 3 zählen kann.

Klar, kann man drüber streiten, kommt aber sicher auch auf den Shop und die Produkte drauf an. Das könnte man ja über die oben genannte "Schärfe/Unschärfe" definieren.

Aber ich weiß aus Erfahrung, dass wenige Suchergebnisse beim Kunden dazu führen, dass er meint, man habe nichts passendes, obwohl einfach nur viele Artikel nicht den entsprechenden Suchbegriff bzw. deren Schreibweise unter "weitere Suchbegriffe" gepflegt haben.

Grüße
Dominik

[ChristianRothe]

@voodoopupp / Dominik: Danke für die Auflistung. Finde ich insgesamt einen sehr stimmigen Anforderungskatalog - der zugleich auch realistischen und umsetzbar ist. Eine Shopsuche mit diesen Fähigkeiten wäre eine klare Bereicherung.

Der Schlüssel zu einer Umsetzung liegt nach meiner Erfahrung in Punkt 1: Aufbau einer Suchtabelle. Später wird dann nur noch in der Suchtabelle gesucht und nicht mehr in den "echten" Produktdaten.

Damit bekäme man zum Beispiel auch Punkt 8 gelöst: Suche in Schlagwortwolken. Dein Beispiel war "lustig/ausgefallen/originell/kreativ/spektakulär/spaßig". Eine Suche nach "lustig" würde eben nicht zur Suchlaufzeit fünf weitere Parallelsuchen nach den anderen Schlagworten auslösen - und damit die Performance in den Keller bringen. Vielmehr wäre ein vernünftiger Ansatz, dass die Texte beim Befüllen der Suchtabelle analysiert werden und dann die weiteren 5 Begriffe dem Text automatisch hinzugefügt werden, wenn im Text "lustig" vorkommt. Dann steht "originell" quasi schon in der Datentabelle drin und wird bei einer späteren Suche nach "originell" ganz normal und einfach gefunden.

[noRiddle (revilonetz)]

Zu Punkt 1:
Exakt, deshalb schrieb ich ja auch anfangs bereits dies:

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

Wollen wir da was zusammen machen ?
Wir, und wer noch möchte, bauen und machen Vorschläge und voodoopupp  Tim,  und wer noch möchte, testen.
Wer sich nicht beteiligt muß einen Obulus abdrücken wenn er's haben möchte.

Gruß,
noRiddle

NACHTRAG:
@voodoopupp
Was ist denn das für ein "Beispiel für Suchbegriffe Dropdown", alles mit "Mädchen" ?
Müssen wir uns Sorgen um dich machen ? 

[ChristianRothe]

Warum sollte man sich selbst eine Indexsuche basteln, wenn man den Volltext-Index von MySQL benutzen kann?

[noRiddle (revilonetz)]

Was du machst/gemacht hast ist aber doch am Ende nichts anderes.

Muß/soll ich das Schweigen zum Rest meines Posts als Wink mit den Zaunpfahl verstehen ?

Gruß,
noRiddle

[Scubi]

Ich kann nicht programmieren, hätte aber die Möglichkeit Daten mit vielen Attributen zur Verfügung zu stellen die sehr schwierig sind, weil kurz. 2-3 Zahlen mit einem Buchstaben (Größen) und entsprechenden Farben. Dazu Synonyme die wirklich umfangreich sind.

[voodoopupp]

Ich bin mir nicht sicher, wie gut die Kölner Phonetik mit kurzen Wörtern und Kleidergrößen umgehen kann. Ich denke, umso kürzer die Wörter, desto kürzer ja der Kölner Phonetik Code und dadurch je unschärfer man dann die Suche stellt, desto schlechter geht die Suche dann vielleicht mit Größen wie XXL vs XL, XS vs XXS usw. um. - kann ich mich aber auch täuschen!

Grundsätzlich finde ich den Ansatz mit der Kölner Phonetik für den deutschen Sprachraum sehr gut!
Wie die Suchergebnisse dann für die englische und auch andere Sprachen sind, sei mal dahingestellt, da würden sich wohl andere Algorithmen besser bewähren (z.B. Metaphone, Soundex etc.).
Aber ich glaube, da die meisten Shops eh primär auf den deutschprachigen Raum abzielen, sollte das auch korrekterweise den Vorrang haben.

Kennt jemand einen Online Tester für Kölner Phonetik,, damit man mal schnell verschiedene Schreibweisen gegeneinander testen kann?
Ich habe hier was gefunden: https://www.qaddress.com/de/blog/phonetische-suche/ (etwas versteckt im Text: "Sie können es hier selbst ausprobieren!")

Da kann man leider immer nur ein Wort einzeln testen, besser wäre es eben wo man direkt mehrere Wörter gleichzeitig vergleichen könnte.
Dann sieht man z.b. die Abweichungen von Schreibfehlern bzw Gleichbehandlung recht schnell:
Größen:
XS: 488
XXS: 488
XL: 485
XXL: 485

ss/ß:
Fußball: 3815
Fussball: 3815

Bei Wikipedia zur Kölner Phonetik sieht man ja, dass folgende Buchstaben generell nicht gewertet werden: A, E, I, J, O, U, Y - daher sind Schreibfehler bei diesen Buchstaben zu vernachlässigen, ebenso Typos wie z.B. g/k oder d/t:
Brotkasten: 1724826
Brtkasten: 1724826
Brtkasten: 1724826
Brtksten: 1724826
Brtkstn: 1724826
Brotgasden: 1724826

Hingegen Verdreher in Konsonanten führen dann zu Abweichungen:
Brotkatsen: 172486

Wenn ich es richtig interpretiere, kann man hier wahrscheinlich als Ergänzung zur Kölner Phonetik noch über die Einbindung der Levensthein Distanz nachdenken, die Abweichungen zwischen zwei Werten besser verarbeiten/berücksichtigen kann, siehe u.a.:
https://de.wikipedia.org/wiki/Unscharfe_Suche
https://de.wikipedia.org/wiki/Levenshtein-Distanz
http://www.levenshtein.de/index.html

[...]
Wollen wir da was zusammen machen ?
Wir, und wer noch möchte, bauen und machen Vorschläge und voodoopupp  Tim,  und wer noch möchte, testen.
[...]

da wäre ich auf alle Fälle dabei.

Würde auch einen entsprechenden Testshop zur Verfügung stellen, wenn ist.
Müsste aber dann erstmal unsere Suche wieder auf normal umbauen, da wir ja schon seit längerer Zeit eine von Alkim verwenden....

[...]
NACHTRAG:
@voodoopupp
Was ist denn das für ein "Beispiel für Suchbegriffe Dropdown", alles mit "Mädchen" ?
Müssen wir uns Sorgen um dich machen ? 

hmm, ich glaube nicht

Hatte zuerst nach "Galaxy" gesucht - aber die Ergebnisse sahen dann dummerweise fast so aus, als ob es Produkte gelistet hätte statt Suchbegriffe

Dann hab ich einfach das erstbeste genommen, was mir in den Sinn kam und ich hoffe, dass es dann auch entsprechende Vorschläge bringt   

[ChristianRothe]

Das Sprachenthema ist ziemlich einfach zu lösen. Ich habe mir eine Klasse searchdata_composer gebaut, die eine Wrapper-Funktion get_phoneticcode_word enthält. Diese Funktion setzt "echte" Wörter in die phonetische Darstellung um. Da hängt dann jeweils ein sprachspezifischer Handler dahinter. Er übernimmt die tatsächliche Umsetzung in phonetischen Code.  So kann ich in jeder Sprache mit eigenen Phonetk-Algorithmen arbeiten. Zumindest theoretisch - denn praktisch gibt es meinen Shop nur auf Deutsch. Aber weitere Sprachen wären mit nur geringem Implementierungsaufwand machbar.

Code: PHP  [Auswählen]

class searchdata_composer {
       
        function __construct($language = null) {

                $this->language = $language ? $language : $_SESSION['language'];
               
                // Sprachspezifischer Handler
                $_languagehandler_classname = 'languagehandler_'.strtolower($this->language);
                $this->languagehandler = new $_languagehandler_classname();            
        }

        function get_phoneticcode_word($word) {
                return $this->languagehandler->phoneticcode($word);
        }

}

class languagehandler_german {
       
        function __construct() {       
                $this->language = 'german';    
        }

        function phoneticcode($word) {
                //  Kölner Phonetik vgl. https://de.wikipedia.org/wiki/K%C3%B6lner_Phonetik
                ...........
        }

}

class languagehandler_english {
       
        function __construct() {       
                $this->language = 'english';   
        }

        function phoneticcode($word) {
                //  Soundex
                ...........
        }

}
 

Die Anwendung wäre also wie folgt:

Code: PHP  [Auswählen]

$sdc = new searchdata_composer('german');
echo $sdc->phoneticcode('Brotkasten');

Die Ausgabe wäre dann 1724826. Und eben entsprechend anders, wenn man eine andere Sprache verwendet.

[voodoopupp]

Hallo Christian,

ich glaube, dass deine Suche schon ziemlich stark vorangeschritten ist und schon ziemlich viele der von mir aufgelisteten Funktionen erfüllt.

Hatte ich ja vorab schon gelesen und ein großer Teil meiner Auflistung basiert ja auch auf deinen Aussagen.

Die Abwicklung der einzelnen Sprachen wäre ja sogar auch schon angedacht bzw. von dir super gelöst. Damit wären auch Erweiterungen für einzelne Sprachen möglich.

Tolle Sache! 

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.
[...]

Beim erneuten Durchlesen des Threads, sehe ich nun, dass du auch hierüber schon nachgedacht hast und dieses Problem wäre wohl auch schon abgedeckt:

[...]
Hingegen Verdreher in Konsonanten führen dann zu Abweichungen:
Brotkatsen: 172486

Wenn ich es richtig interpretiere, kann man hier wahrscheinlich als Ergänzung zur Kölner Phonetik noch über die Einbindung der Levensthein Distanz nachdenken, die Abweichungen zwischen zwei Werten besser verarbeiten/berücksichtigen kann, siehe u.a.:
https://de.wikipedia.org/wiki/Unscharfe_Suche
https://de.wikipedia.org/wiki/Levenshtein-Distanz
http://www.levenshtein.de/index.html
[...]

Löst du das über eine solche Funktionalität?

Ich glaube du must dich mal mit noRiddle zusammenschalten, evtl. könnten wir das wirklich lauffähig bekommen - das wäre eine geniale Sache!!!

Viele Drüße
Dominik

[Viol]

Mit meinem offline 2.0.6.0 Testshop könnte ich mich gerne als Tester zur Verfügung stellen.

[ChristianRothe]

[...]

[...]
Hingegen Verdreher in Konsonanten führen dann zu Abweichungen:
Brotkatsen: 172486

Wenn ich es richtig interpretiere, kann man hier wahrscheinlich als Ergänzung zur Kölner Phonetik noch über die Einbindung der Levensthein Distanz nachdenken, die Abweichungen zwischen zwei Werten besser verarbeiten/berücksichtigen kann, siehe u.a.:
https://de.wikipedia.org/wiki/Unscharfe_Suche
https://de.wikipedia.org/wiki/Levenshtein-Distanz
http://www.levenshtein.de/index.html
[...]

Löst du das über eine solche Funktionalität?
[...]

Ich habe einfach einen zweistufigen Suchprozess implementiert:

• Schritt 1: Phonetische Suche
• Falls Schritt 1 ohne Treffer bleibt, dann - aber auch nur dann - führe Schritt 2 aus: Fuzzy Suche

Dabei verwende ich die Fuzzy Suche, die es schon Ewigkeiten für XTC bzw. den Modified Shop gibt.

[p3e]

Da ich mich bereits vor vielen Jahren mit der Optimierung der Suche in einem anderem Zusammenhang beschäftigt habe, wollte ich meine Erfahrung dazu teilen.

Fehlertoleranz und Automatisierung ist sicherlich gut. Man sollte aber nicht einen Index, der mit Synonymen angereichert werden kann, vernachlässigen. Eine Kombination von beidem wäre dann die Krönung.
Als Shop-Betreiber weiß ich, dass ein guter Shop auch gepflegt sein will. Was der Shop-Betreiber braucht, ist neben der sehr guten Suche auch eine Möglichkeit, eine Suchwortstatistik auszuwerten und Worte mit schlechten Ergebnissen anderen Synonymen zuzuordnen, die bessere Ergebnisse bringen. Mit Synonymen meine ich nicht nur Begriffe mit gleicher Bedeutung sondern auch mit anderer Schreibweise oder gar mit Tippfehlern.
Als Student hatte ich vor vielen Jahren den Auftrag eine möglichst effektive Suche zu programmieren. Das war für eine Bildagentur mit  über 500.000 Fotos. Die Suche die es bis dahin gab war aufgrund der großen Datenbank mit Stichworten und Beschreibungen zu den Bildern sehr langsam. Außerdem war die Verschlagwortung nicht einheitlich geschehen. Es gab unterschiedliche Ergebnisse, wenn man z.B. nach Frucht oder nach Früchten suchte.
Vorgabe war, dass die Suche deutlich schneller wird und erweitert werden kann. Ich hatte das über eine Index-Suche gelöst. Die Suche wurde dadurch extrem schnell. Die Datenbank für die Indexsuche bestand im Grunde aus zwei Spalten (Suchworte + Synonymen und in der anderen Spalte alle Bildnummern die zu dem Suchwort ODER einen der Synonyme passt).
Beispiel:
Möhre, Karotte, Wurzel, Möhren, Karotten, Wurzeln, Gemüse, Nahrung, Nahrungsmittel, Vitamine, Nutzpflanze, Nutzpflanzen | 1nj553, 1ud658, 4kd128, 4ad129, 5lh263 (Bildnummern)

Die Indexierung könnte manuell angestoßen werden und wurde zusätzlich automatisiert bei Anpassung eines Artikels nur für diesen Artikel und bei Anpassung der Synonyme nur für die neuen Worte durchgeführt.
Durch den Index waren auch logisch verknüpfte Suchanfragen mit AND, OR oder NOT sehr schnell möglich.

Später bekam ich den Auftrag, dass die Bildagentur Kunden mit einem kurzen Link eine manuelle Bildzusammenstellung schicken kann. Dazu habe ich die Indexsuche nutzen können, indem einem temporäres Suchwort (z.B. Kunde123_15032001) bestimmte Bilder zugeordnet wurden und der Kunde der entsprechende Suchlink gemailt wurde. Im Suchwort war zusätzlich ein Verfalldatum (in dem Beispiel 15.02.2001) hinterlegt, ab dem der Eintrag wieder gelöscht wurde.

[voodoopupp]

Da ich mich bereits vor vielen Jahren mit der Optimierung der Suche in einem anderem Zusammenhang beschäftigt habe, wollte ich meine Erfahrung dazu teilen.

Fehlertoleranz und Automatisierung ist sicherlich gut. Man sollte aber nicht einen Index, der mit Synonymen angereichert werden kann, vernachlässigen. Eine Kombination von beidem wäre dann die Krönung.
Als Shop-Betreiber weiß ich, dass ein guter Shop auch gepflegt sein will. Was der Shop-Betreiber braucht, ist neben der sehr guten Suche auch eine Möglichkeit, eine Suchwortstatistik auszuwerten und Worte mit schlechten Ergebnissen anderen Synonymen zuzuordnen, die bessere Ergebnisse bringen. Mit Synonymen meine ich nicht nur Begriffe mit gleicher Bedeutung sondern auch mit anderer Schreibweise oder gar mit Tippfehlern.
[...]

[...]

• [...]
• Suche nach ähnlichen Wörtern/Synonymen (Zitrone, Citrus, Zitrusfrucht...)
• "Schlagwortwolken", sprich Gruppierungen von unterschiedlichsten Wörtern, z.B. lustig/ausgefallen/originell/kreativ/spektakulär/spaßig
  ---> wenn also "lustig" gesucht wird, und Artikel A einen Treffer z.B. in der Artikelbeschreibung hat, soll auch Artikel B augeliefert werden, obwohl dieser nur "originell" im Text hat
• [...]

[...]

Das würde sich ja dann definitiv mit meiner Aussage decken und auch ich bin der Meinung, dass dieser Baustein wahrscheinlich sogar wichtiger ist als die Fehlertoleranz.

Denn Suchen nach Brotkasten, sollte eben auch Brotkorb, Brotbeutel, Brotsack ausspucken - und diese sind nur über passende Synonyme auffindbar.

Allerdings macht es keinen Sinn, diese bei jedem neuen Produkt aus dieser Gruppe immer wieder jedes Wort einzeln an die Artikel zu mappen!

Und genau das ist eine der Fragen, wie man das sauber löst ohne jedesmal alles manuell über irgendwelche IDs hinzuzufügen 

Vielleicht könnte man ja eine Art Tabelle mit "Wortwolken" bauen, in jede Wolke kommen passende Begrifflichkeiten für ein und dasselbe Thema (andere Bezeichnungen, fehlerhafte Schreibweisen etc.)
Beispiel: "Bierglas,Weizenbierglas,Weißbierglas,Weissbierglas,Weißbiergläser,Weissbiergläser,Weizenglas,Weizen,Hefeweizen, Weißbiertulpe"

Wenn man nun ein Produkt pflegt, prüft ein Cronjob, ob Wörter des Produkttitels in diesen Wolken vorkommen. Wenn ich also ein neues Produkt anlege "Weizenbierglas 0,5l mit Logo der Manufaktur XYZ", dann prüft der Cronjob, ob eines der Wörter in den Wolken vorkommt und speichert diese ebenso mit in die Suchtabelle ab.

Er findet also "Weizenbierglas" und nimmt die gesamte Wolke und speichert sie mit ab.

Sinnvollerweise müsste das dann wahrscheinlich auf ganze Wörter prüfen, denn wenn ich ansonsten noch zusätzlich das Produkt "Langstielige Tulpe aus Kunststoff" anlege, dann würde er bei Teilwörtern "Weißbiertulpe" finden und dann ebenso alles dazu matchen

[...]

[...]
Hingegen Verdreher in Konsonanten führen dann zu Abweichungen:
Brotkatsen: 172486

Wenn ich es richtig interpretiere, kann man hier wahrscheinlich als Ergänzung zur Kölner Phonetik noch über die Einbindung der Levensthein Distanz nachdenken, die Abweichungen zwischen zwei Werten besser verarbeiten/berücksichtigen kann, siehe u.a.:
https://de.wikipedia.org/wiki/Unscharfe_Suche
https://de.wikipedia.org/wiki/Levenshtein-Distanz
http://www.levenshtein.de/index.html
[...]

Löst du das über eine solche Funktionalität?
[...]

Ich habe einfach einen zweistufigen Suchprozess implementiert:

• Schritt 1: Phonetische Suche
• Falls Schritt 1 ohne Treffer bleibt, dann - aber auch nur dann - führe Schritt 2 aus: Fuzzy Suche

Dabei verwende ich die Fuzzy Suche, die es schon Ewigkeiten für XTC bzw. den Modified Shop gibt.

Welche Fuzzy Suche meinst du? Meinst du die hier: Fehlertolerante Suche – Fuzzy Search (veraltet)

Und wie genau muss ich das verstehen: die Fuzzy Suche liegt erstmal generell brach, und nur, wenn aus der Such-Datenbanktabelle nichts geliefert werden kann, springt diese "live" an?
Also die sucht dann direkt wie die normale Suche im Livebestand? Oder ist auch diese generell schon irgendwie in eine weitere Datenbanktabelle abgespeichert?

Grüße
Dominik

[karsta.de]

[...]
Vielleicht könnte man ja eine Art Tabelle mit "Wortwolken" bauen, in jede Wolke kommen passende Begrifflichkeiten für ein und dasselbe Thema (andere Bezeichnungen, fehlerhafte Schreibweisen etc.)
Beispiel: "Bierglas,Weizenbierglas,Weißbierglas,Weissbierglas,Weißbiergläser,Weissbiergläser,Weizenglas,Weizen,Hefeweizen, Weißbiertulpe"
[...]

Das könntest du doch über die Eigenschaften-Filterfunktion (oder diese Duplizieren) TAG 'Wortwolken' umsetzen und die Filterfunktion und Anzeige für diese Eigenschaftsgruppe ausschließen. Denn die Tags (Suche in Artikeleigenschaften) kannst du standardmäßig in die Suche mit einbeziehen. Finde das allerdings  genauso aufwändig wie die Zahlenvariante.

BG Karsta

[voodoopupp]

Das hatte ich mir auch schon überlegt, denke aber es wäre irgendwie mühselig & unübersichtlich, denn das müsste man fast für jeden Artikel direkt anlegen.

Teilweise würde es definitiv Sinn machen, wenn man das z.B. für Farben/Materialien oder ähliches nutzt.
Dachte schon daran, dafür in den Artikeleigenschaften das Feld "Beschreibung" zu missbrauchen, also so etwa:
[ Für Gäste sind keine Dateianhänge sichtbar ]

Ich habe aber bemerkt, dass wir oftmals ganz "abartige" Suchanfragen haben, die mit dem Produkt selbst eigentlich wenig zu tun haben, an sich aber passend sind. Aber dafür extra einen neuen Artikeleigenschaften-Suchbegriff einzuführen, macht wenig Sinn. Dann tragen wir also stattdessen in dem Moment diese Wort bei passenden Artikeln dann in die weiteren Suchbegriffe ein. Danach ist es aber vergessen, wenn ein gleicher Artikel in 4 Monaten erneut eingepflegt wird.

Wenn man aber doch für jeden noch so komischen Begriff eine neue Artikeleigenschaft anlegt, , werden die Artikeleigenschaften dann so lang, dass es beim Artikelpflegen sicher keinen Spaß mehr macht.
Vor allem, wenn man wieder nicht genau weiß, unter welchem "Hauptwort" man was abgespeichert hat - hab ich das Wort "Pensionär" nun unter Opa, Großvater, Großpapa, Ahne, Greis, Senior, Ruhestand, Pension oder Rente gespeichert?

Da wären unabhängige Wortwolken besser, die man eben z.B. über den Titel bzw. weitere Suchbegriffe automatisiert ansprechen könnte.

Grüße
Dominik