Lieber Support,

wir benötigen nach wie vor eine Preissuch-Funktion ('von-bis') für Subkataloge.
Die Anordnung von Produkten in Subkatalogen gibt es bereits so lange bei Shoppilot.
Da sollte es unserer Ansicht nach auch eine Preissuche 'von-bis' für Subkataloge geben.
Ist diese Funtion denn so schwer einzurichten?

Aktuellen Untersuchungen zufolge ist die Suchfunktion extrem wichtig für einen
guten Shop. Das wussten wir doch schon immer, oder...?
;)
jg

Hallo Jg,

die Preissuche bei Subkatalog ist nicht schwierig, aber exterm performance-fressend,
wesshalb sie nicht realisiert ist. Dies kommt daher weil hier Mischfälle zu beachten sind,
für Artikel A kommt der Preis aus dem Hauptkatalog, für Artikel B aber nicht.
Generell können komplexe Preisfindungen, wie auch Artikelwarengruppenrabatt, Kundenrabatt oder Preisfaktor
nicht in die Preissuche eingehen, da sie nicht per (einfacher, einer) SQL Abfrage zu realisieren sind.

Wir sind von folgendem ausgegangen:
1. Preissuche ist etwas für Endkunden, die nicht wissen was Sie kaufen sollen.
2. In Endkundenshops (verschiedener Händler) gibt es aber keine starken Preisunterschiede.
3. Es ist nicht wichtig, dass der Bereich wirklich zu 100% getroffen wird. (Wenn Ich Bereich 30-50 EUR wähle
ist es nicht schlimm, wenn auch Artikel für 24,96 oder 59,60 angezeigt werden).

Gruss hop

Hallo hop,

an der Länge des Beitrags sehen Sie, wie wichtig mir (auch) dieses Thema ist.

> die Preissuche bei Subkatalog ist nicht schwierig, aber exterm performance-fressend,
> wesshalb sie nicht realisiert ist. Dies kommt daher weil hier Mischfälle zu beachten sind,
> für Artikel A kommt der Preis aus dem Hauptkatalog, für Artikel B aber nicht.
Mag sein, dass es in anderen Shops so läuft - bei uns kommt die Preisanzeige immer
nur aus einem (Sub)Katalog (zB. DE, FR, ENG). Ein Kunde kann sich ja nicht _gleichzeitig_
in mehreren Subkatalogen bewegen...
Vielleicht könnte man hier auch ansetzen, dass die Suche dahingehend erweitert wird,
dass eben _nicht_ quer durch verschiedene Kataloge gesucht wird, sondern entweder
im Hauptkatalog oder in dem jeweiligen gerade aktiven Subkatalog, in dem sich 'Kunde'
gerade befindet. Das würde doch sicher keine zusätzliche Performance wegnehmen.

Es nutzt (uns) nichts, wenn man Preise in einem Subkatalog unterschiedlich definieren kann
(Stichwort: Schalter "Original benutzen"). Ursprünglich sind Subkataloge ja auch für das
Einrichten unterschiedlicher Sprachen bzw. die Anzeige von verschiedenen 'Preislisten' gedacht.
Gerade wenn man mit dem Import aus einer WaWi arbeitet, wäre es einfach zu aufwendig
und zu kompliziert (wenigstens für uns), Preise von tausenden von Artikeln in Haupt- und
Subkatalog zu vermischen. Hier sagen wir ganz einfach, Subkat A hat die Preisliste A,
Subkat B die Preisliste B usw. - Fertig.
Daten aus einer WaWi zu 100% in SP zu importieren ist doch gerade das GROSZE Plus von SP!!
Zur Zeit funktioniert die Von-Bis-Preissuche in Shoppilot ja nur im Hauptkatalog.
Dann funktioniert sie eben immer nur im gerade aktiven Haupt-/Subkatalog.

Wir haben da also einen anderen Denkansatz und der geht noch weiter, unser Vorschlag:
1. die einfache Suche so belassen wie sie ist
2. zusätzlich dazu eine neue Seite/Funktion 'Erweiterte Suche' einrichten, die dann
mit einer neuen Suchergebnisseite verknüpft wird (vielleicht auch für Andi geeignet!!).
In der kann 'Kunde' dann eine Von-Bis-Preissuche u.a. definieren (auch eine Sortierung),
wenn er will. Auf so eine Seite könnte zur Not auch ein Hinweis rein, dass die
'Erweiterte Suche' evtl. einen Moment länger dauert... ;)
Jeder Shopbetreiber könnte so selbst entscheiden, ob er diese 'Erweiterte Suche'
nutzen will oder sie aus Performance-Gründen lieber nicht einbaut.
Wir haben zB. nicht soo viele Kunden am Tag, die sich da ggs. die Performance klauen,
dafür sind es aber meistens größere 'Besteller' die auch ordentlich was finden wollen.

Suchergebnisse kann man glaube ich auch in Arrays 'packen' und dann damit in Perl
'performance-freundlich' weiterarbeiten. So wäre vieleicht auch mal eine Ausgabe
des Suchergebnisses möglich, dass sich (vorher) nach unterschiedlichen Kriterien
sortieren lässt, zB. Preis auf-/absteigend oder Titel auf-/absteigend (wurde auch
schon mal hier angesprochen).

> Generell können komplexe Preisfindungen, wie auch Artikelwarengruppenrabatt,
> Kundenrabatt oder Preisfaktor nicht in die Preissuche eingehen,
> da sie nicht per (einfacher, einer) SQL Abfrage zu realisieren sind.
Das ist nachvollziehbar und für uns auch nicht notwendig. Uns geht es mehr
um das sinnvolle Finden, Auflisten, Sortieren ALLER Datenbankinhalte.
DB werden mit den Jahren leider immer voller...

> Wir sind von folgendem ausgegangen:
> 1. Preissuche ist etwas für Endkunden, die nicht wissen was Sie kaufen sollen.
Nein. Bei uns arbeiten(!) Stammkunden manchmal bis zu mehreren Stunden im Shop,
lösen eine Bestellung über 'zig Dutzende von Artikeln aus. Diese Kunden wären
uns sicher dankbar für jede 'Erweiterte Suche' die sie kriegen können!
B2B-Bestellungen sind teilweise Schwerstarbeit... (!)
Dabei immer die richtigen Preise im Auge zu behalten, hat da Priorität.

> 2. In Endkundenshops (verschiedener Händler) gibt es aber keine starken Preisunterschiede.
Verstehe ich nicht richtig. Unsere Händler bieten Artikel von 2 bis 500 EUR
oder sogar mehr an. Ist das kein Unterschied?

> 3. Es ist nicht wichtig, dass der Bereich wirklich zu 100% getroffen wird.
> (Wenn Ich Bereich 30-50 EUR wähle ist es nicht schlimm, wenn auch Artikel
> für 24,96 oder 59,60 angezeigt werden).
Oh doch, _das_ist_wichtig_! Wenn ich im Laden zum Verkäufer sage: Ich möchte
ein Geschenk bis max. 30 EUR, wäre ich sauer, wenn mir der Verkäufer dann
etwas für 35 EUR zeigt. Dann würde ich ihn fragen ob ich genuschelt habe
oder er schwerhörig ist (auch wenn' s etwas überheblich klingt).

Und besonders unsere Einzelhändler sind ganz empfindlich momentan, wenn Sie
nicht die Ware finden zu den Preisen, die sie sich vorstellen. Ich weiß nicht,
bei welchem Einzelhändler der Wirtschaftsaufschwung in DE angekommen ist.
Bei unseren Kunden jedenfalls nicht - und das sind einige...
Gerade Händler wollen genau _die_ Preise, die sie sich vorstellen. Viele suchen
zB. Artikel bis max. Betrag X. Preise ÜBER Betrag X wollen die gar nicht sehen.
Vielleicht wollen sie die Ware dann bei eBay weiterverkaufen. Dort wiederum
gibt es diese 'berühmten' Preisschwellen, nach denen eBay den Händlern
seine Preise berechnet. Da hängt eins vom anderen ab.
Natürlich gibt es sicher auch andere Händler, die eine 'tolerante' Preissuche
akzeptieren würden. Wir müssen aber leider an die Mehrheit der Händler denken,
denen zuerst der beste Preis im Kopf rum geht und (leider) nicht das beste Design
oder die beste Qualität.

PS: Bin auch bereit, einen 'Modulpreis' für eine komplexe 'Erweiterte Suche' zu zahlen.
So wichtig ist uns diese Funktion... [seufz] 
Wer legt mit mir noch etwas Geld dazu?   ???

Grüße, jg

Hallo jg,

Habe (vielleicht) eine Lösung für dieses Problem :D

Da ich sehr kleine Preise habe ( 90% meiner Artikel liegen zwischen € 2,00 - 5,00 ) und daher eine Preissuche nur im genauen Centbereich Sinn macht, habe ich mir eine eigene Suchfunktion gebaut.
(Nebeneffekt: ich kann auch beliebig viele unterschiedliche Ergebnisseiten anlegen)

Ich habe allerdings nur einen Händler und keine Subkataloge - kann also nicht testen, ob es für Ihr Problem auch verwendbar ist.

Hier mal das Script:
<!--spmacro:module(suchen)
sub ausgabe {

my $preisx = ssp::get_var_form('suchvon');
my $preisy = ssp::get_var_form('suchbis');
my $suchbegriff = ssp::get_var_form('suchbegriff');
my $count = ssp::readSQLData("SELECT ITEMID, PRICE, WISUCHEN,  ARTIKEL, MARKE FROM PY2_ITEM","ITEMID","PRICE","WISUCHEN","ARTIKEL","MARKE");  # hier ALLE Felder eintragen, in denen gesucht werden soll
if ($count >= 0) {
my $i=0;
while ($count > $i) {
my $artikel = ssp::get_var_db("ITEMID",$i);
my $preis = ssp::get_var_db("PRICE",$i);
my $suchen1 = ssp::get_var_db("WISUCHEN",$i);
my $suchen2 = ssp::get_var_db("MARKE",$i);
my $suchen3 = ssp::get_var_db("ARTIKEL",$i);
$preis =~ tr/,/./;
$preisx =~ tr/,/./;
$preisy=~ tr/,/./;   # ersetz "," durch "." -> ist also auch egal, ob der Kunde Preis mit "." oder ";" eingibt
$suchbegriff=~ tr/[A-Z]/[a-z]/;
$suchen1=~ tr/[A-Z]/[a-z]/;
$suchen2=~ tr/[A-Z]/[a-z]/;
$suchen3=~ tr/[A-Z]/[a-z]/;  # es wird kein Unterschied zwischen Groß- oder Kleinschreibung gemacht

if (($preis >=$preisx) && ($preis <=$preisy) && (($suchen1 =~ /$suchbegriff/) || ($suchen2 =~ /$suchbegriff/) || ($suchen3 =~ /$suchbegriff/)))  {
my $out = qq |$artikel,|;
my $str = ("$out,");
ssp::embedded("csearch","suchanz.txt",$str );  # beliebige txt Datei für die Ausgabe
}
++$i;
}
} 
}
-->

Die DB-Abfrage (Tabelle und Felder in denen gesucht werden soll) muß natürlich angepasst werden)
Infoseite für Ausgabe der Ergebnisse usw ist sicher klar, im Suchformular dann action="__xsuchen__"  durch  action="__xxpath__?showSeitennummer_der_Infoseite,__xxsession__" ersetzen
und - falls Sie das möchten - für die eigene "von - bis" Preiseingabe
      <input type="text" name="suchvon" value="" size="5" onFocus="this.value=''" class="textfeld">
      <input type="text" name="suchbis" value="" size="5" onFocus="this.value=''" class="textfeld">
statt der Listbox einfügen.
Würde mich freuen, wenn diese Lösung für mein Problem auch hier funktionieren würde  ???

Hallo Dobra,

Danke für dein Skript. Deine Idee die DB direkt abzufragen ohne __xsuchen__
hatten wir auch schon. Wir werden das wohl auch so oder so ähnlich einbauen.
Für mich gibt es aber auch noch folgende Variante als Lösung, die ich in einem
anderen Shop gesehen habe. Da geben _wir_ die 'Von-Bis-Preise' vor -
Kunden müssten dann einfach nur noch eine Wahl treffen und drauf klicken.
Der Vorteil daran wäre, dass wir die Performance hier vorher bereits testen können
und ein User nicht unbedingt noch bestimmte Werte in Felder eingeben muss.
Das würde mir im Prinzip schon reichen:
http://www.amazon.de/s/ref=sr_hi/302-4283328-9996836?ie=UTF8&rs=&me=A2RSP7W4D0MO5U
linke Seite, Preis von-bis...
Ich melde mich wieder, wenn wir für uns eine Lösung umgesetzt haben.

Grüße, jg

Funktioniert ja mit vorgegebenen Preisen genauso
(http://www.shoppilot.net/pf/empty-t105.0.html;msg392#msg392)

Auszug:

Zitat- Suche mit Preisbereich
Es ist jetzt möglich, die Suche auf einen Preisbereich einzuschränken.
Dazu dienen im Suchformular die Felder "suchvon" und "suchbis".
Es werden die Preise aus dem Hauptkatalog für die Suche berücksichtigt.
Beispiel:
von:
<select name="suchvon" size="1">
<option value=0 selected>egal</option>
<option value="20">20 €</option>
<option value="100">100 €</option>
<option value="200">200 €</option>
</select>
bis
<select name="suchbis" size="1">
<option value=99999999 selected>egal</option>
<option value="50">50 €</option>
<option value="100">100 €</option>
<option value="250">250 €</option>
</select>

Ist sicher einerseits Geschmacksache und andererseits je nach Shop-Anspruch besser, die eine oder andere Form zu wählen.
Bei den vorgegebenen Preisen sehe ich (persönliche Meinung) den Nachteil, daß der Kunde dann z.B. nur nach 5 - 10 oder 10 - 20, nicht aber 5 - 25 suchen kann

Nachteil von meinem Script ist allerdings, daß die Suche wesentlich langsamer geht, als mit __xsuchen__

> Funktioniert ja mit vorgegebenen Preisen genauso...
Eben nicht bei uns, da standardmäßig nur der Hauptkatalog abgefragt wird,
wir aber die Preissuche mit der Tabelle ISCAT verbinden müssen.

> Nachteil von meinem Script ist allerdings, daß die Suche wesentlich langsamer geht, als mit __xsuchen__
Dazu noch eine Anmerkung von mir für den Support:
Wir haben auch den Eindruck, dass DB-Abfragen die über SSP-Funktionen wie 'ssp::readSQLData'
gesteuert werden nicht so schnell sind, als wenn der Datenbankzugriff direkt über das Modul DBI erfolgt.
Wir haben früher in unserem alten Shop mal damit gearbeitet, als es die DB-SSP-Funktionen noch nicht gab...  ;)
Das nur mal als Hinweis. Vielleicht lässt sich die Permance der SSP-DB-Befehle ja noch etwas optimieren.  (?)

Grüße, jg

> Funktioniert ja mit vorgegebenen Preisen genauso...
Mißverständnis?  ich meinte mein Script (also die direkte DB-Abfrage) funktioniert genauso mit vorgegebenen Preisen.

Das Script ist ja auch nur als Lösungsansatz gedacht
- kann natürlich noch in alle Richtungen (je nach Shop-Voraussetzungen und Berdarf) erweitert werden.
Auch die Lösung auf der Beispielseite kann man nach diesem Schema nachbauen.

@ support
wenn ich die Forumsbeiträge nicht schon (fast) auswendig kennen würde  ;) hätte ich die "Bausteine" nicht gefunden.
Vielleicht könnt man die "normale Preissuche" wie hop es  hier
("Enterprise 1.5.16 « am: Dezember 10, 2002, 13:38:51 »)
beschrieben hat, auch in die Doku oder online-Hilde schreiben?

Wichtiger Nachtrag: in meiner Begeisterung, daß ich eine Lösung für mein "Preissuche-mit-Kommazahlen" Problem gefunden habe, habe ich vergessen zu betonen, daß mein Script die __xsuchen__ Funktion nicht ersetzten kann !!!
Alle im Shop integrieren Suchfunktionen sind natürlich wesentlich komplexer = besser und vielfältiger.
Ich werde das auch weiterhin so verwenden  und mein zusammengebasteltes Script nur wegen der Kommazahlen für eine separate Preissuche einbauen.

Hallo zusammen,

ich muss mal meine Bemerkungen dazu los werden.
Grundsätzlich funktioniert das Script von dobra (habs jetzt zwar nicht getestet, aber von der Logik her ist es korrekt).
Nur es hat genau die Probleme mit der Performance die ich schon oben angedeutet habe.
Warum ? Weil hier nicht per SQL gesucht wird und alle Artikel für die Suche eingelesen werden und in den Hauptspeicher
geladen werden. Das ist um Grössenordnungen langsamer als per SQL zu suchen und verbraucht jede Menge Hauptspeicher.
Deshalb würde ich eine solches Vorgehen nicht empfehlen, es sei denn man kann sicherstellen, dass insgesamt  nicht mehr als
wenige hundert Artikel eingelesen werden.

Gruss hop

 

Danke dobra, danke hop. Jetzt ist die Problematik für uns schon viel klarer.
Wenn wir eine Lösung umgesetzt haben, melde ich mich noch einmal...

jg

Noch ein kleiner Hinweis zum "basteln"

Man kann eine Vorauswahl bei der SQL-Abfrage einbauen.
Dadurch werden nicht alle Daten in den Hauptspeicher geladen wodurch die Suche wesentlich beschleunigt wird.

Bin gerade beim testen - schaut gut aus  :D

my $count = ssp::readSQLData("SELECT Felder in denen gesucht werden soll FROM PY2_ITEM WHERE Auswahlfeld LIKE'%$suchbegriff%'","...

Diesen Codeschnippsel habe ich gesucht und gefunden:   LIKE'%xx%'  = wenn xx enthalten ist
z.B.  Auswahlfeld = langer Beschreibungstext und Suchwort = xx
->  nur wenn xx irgendwo im Text vorkommt, wird die Artikelnummer ausgelesen.
(auch mit && und || verwendbar)

Damit auch hier Groß- und Kleinschreibung nicht berücksichtigt wird, muß man allerdings das
$suchbegriff=~ tr/[A-Z]/[a-z]/;
dann vor die SQL-Abfrage stellen.

Nachtrag: SQL Syntax zu nachlesen http://sql.1keydata.com/de/sql-syntax.php

Hurra - Erste Erfolge - mal gucken ? http://www.woll-insel.at/cgi-bin/shop2/iboshop.cgi?show1200005210
   (fehlt noch "weitere Seiten" und "mehr als ein Suchbegriff")  <- erledig
- aber es kommt ja wieder ein Wochenende  ;))   

Aber nochmal - diese "erweiterte Suche" werde ich nur zusätzlich als Alternative zu der viel besseren und schnelleren __xsuchen__ Funktion einbauen.