Hi aerodrome,
ich fürchte, dass wird so kaum sinnvoll machbar sein, d.h. es wäre unverhältnismäßiger Aufwand und würde dann zu Lasten der Performance gehen und ein Suchverhalten bieten, welches ich als Kunde nicht erwarte. Ich kann mir auch keinen Fall vorstellen, wo es mir einen entscheidenen Vorteil brächte, solch eine Suchsortierung zu haben(?).
Außerdem gibt es ja die Möglichkeit, in den Ergebnislisten manuell zu sortieren, was Deinen Ansatz dann wieder zunichte machen würde. Ich glaube also, dass es den Kunden sogar eher verwirren könnte, und würde es persönlich so nicht umsetzen.
Sinnvoller könnte es evtl. sein, eine Art Prioritätsattribut für Artikel einzuführen, welches dann der Standardsortierung dient, solange keine andere Sortierung vom Kunden gewählt wird. Macht aber Arbeit, dass alles “doppelt” zu pflegen, und man sollte dem Kunden auch irgendwie signalisieren, wonach nun genau sortiert wird. Ohne weitere Infos sieht das dann nämlich eher nach Zufall als gewollt aus…
Denkbar wäre auch, die Suche um ein Auswahlfeld zu ergänzen, wonach genau gesucht werden soll (z.b. nur Titel), aber auch das dürfte den Kunden nur bedingt helfen.
Das Problem ist halt, dass die Suche über eine einzige SQL-Query läuft, und dort steht dann z.b.:
SELECT ... WHERE ... AND ( oxv_oxarticles_de.oxtitle like '%kite%' or oxv_oxarticles_de.oxshortdesc like '%kite%' or oxv_oxarticles_de.oxsearchkeys like '%kite%' or oxv_oxarticles_de.oxartnum like '%kite%' or oxv_oxartextends_de.oxtags like '%kite%' )
Für Deine Lösung müsste man nun für JEDES “like” eine eigene Suche starten und am Ende alles wieder zusammenfügen, was recht aufwändig in der Umsetzung wäre, gerade im Verhältnis zum fraglichen Nutzen.
Gruß mm