Strategie: Produktfilter wie bei "eBay"

[schmidtsmikey]

Hallo zusammen,

ich stehe vor einem Projekt, einen dynamischen und universellen Filter auf Produktlisten zu programmieren und benötige hierfür einfach mal ein paar grobe Richtungen / Strategien, in die ich mich einlesen kann.

Als Vorbild nenne ich mal eBay (Beispiel-Kategorie) oder Testberichte (Beispiel-Kategorie).

Unversell heißt für mich: es gibt unterschiedliche Kategorien mit unterschiedlichen Produktattributen (ein Smartphone hat andere Attribute wie ein Fernseher)

Dynamisch heißt für mich, dass die Listen nach Betätigung neu erstellt werden (komisch ausgedrückt, aber das was man typischerweise erwartet, wenn man filtert).

Ich bin immer wieder auf die Kombi jQuery + AJAX gestoßen und stehe kurz davor, mir Literatur zu beiden Themen zu besorgen (PHP, MySQL, JavaScript-Grundlagen Kenntnisse habe ich).

Wäre ein Pro oder Kenner so nett, mir die grobe Richtung sagen, bevor ich in den endlosen Weiten der <forms> und $_POST untergehe :-) Eventuell gibt es ein passendes Online-tutorial, welches ich bis jetzt noch nicht gefunden habe.

Vielen Dank!

[Kropff]

Vielleicht hilft dir das Tutorial weiter.

Peter

[ezkimo]

Ich habe soetwas für einen meiner Kunden für die Ergebnisansicht in einem Vergleichsrechner realisiert. In puncto Herangehensweise gab es hier mehrere Ideen. Von der eigentlichen Idee her ähnelt es aber Deinem beschriebenen Vorhaben. Grundsätzlich wird die Filterung der Ergebnisse mit Ajax / Javascript umgesetzt. Zuerst wird ein Gesamtergebnis ermittelt. Anhand mehrerer Filter-Optionen kann der User aus diesem Ergebnis, je nach gewähltem Filter, auch nur eine Teilmenge anzeigen lassen. Die Filter sind als Radio Buttons aufgelistet und auch kombiniert auf das Ergebnis anwendbar.

Sobald der User eine Filteroption wählt, wird asynchron per Javascript eine PHP Datei aufgerufen, die das Gesamtergebnis nach gewähltem Filter auswertet und zurückgibt. Das zurückgegebene Ergebnis wird per Javascript in das vorhadene DOM eingebunden.

Du solltest Du eventuell auch Gedanken über das Thema Cache machen. In meinem Fall wird das Gesamtergebnis zwischengespeichert. So wird das Gesamtergebnis nur einmal aus einer MySQL Datenbank ermittelt. Danach wird das zwischengespeicherte Ergebnis immer wieder durch die gewählten Filter durchlaufen. Anstatt bei jeder Filterung eine neue Datenbankabfrage auszuführen, wird das zwischengespeicherte Ergebnis immer wieder durchlaufen. In diesem Zusammenhang macht es eventuell auch Sinn sich den FilterIterator anzusehen.

... und lies Dir auf jeden Fall das Tutorial vom Kropff durch.

[schmidtsmikey]

Hallo, vielen Dank für die Rückmeldung. Ich habe heute begonnen, mir das Tutorial anzuschauen. Genau in die Richtung soll es gehen.

Leider ist in dem Tutorial der Part mit den MySQL-Abfragen etwas zu kurz gekommen, und der Fokus liegt auf dem AJAX-Handling.

Zur Zeit grüble ich über folgende Punkte nach:

• Wie kann ich Formularfelder und die anschließende Auswertung mit WHERE-Bedingungen im SQL-Query so vereinheitlichen, dass sämtliche Informationen aus der DB kommen. Aufgrund der Komplexität (Zwar gleicher Produktstamm (Hersteller, Preis usw.), aber hunderte Kategorien mit unterschiedlichen Produkt-Eigenschaften) kann ich unmöglich für jede Produkteigenschaft ein Formularfeld hard in den Quellcode schreiben. Dann sitze ich in 10 Jahren noch dran. Informationen über Produkteigenschaften liegen relational in der Datenbank und liefern Infos über Formulartyp (Text, Radio, Select usw). Ich werde mir also eine Klasse programmieren, die die formularfelder generiert, eindeutig definiert und Filter / Where Anweisungen dementsprechend setzt.
• Warum muss ich das komplette Ergebnis der Datenbankabfrage in XML oder JSON vorhalten, um dann darauf zu filtern? Warum nicht einfach eine neue DB-Abfrage mit den entsprechenden Where-Bedingungen? Dann würde ich AJAX dazu verwenden, um die Seite nicht neuzuladen.

[ezkimo]

Zu Deinen Fragen:
1. Du könntest alle zugeordneten Eigenschaften und Kategorien mit der Suchabfrage ermitteln und diese dann so gruppieren, dass deren Ausgabe einen Sinn macht. Eventuell macht es auch Sinn nicht alle Eigenschaften auf einmal auszugeben. Ähnlich wie bei Amazon z.B., welche die Eigenschaften zu einem Produkt erst nach und nach zur Auswahl bereit stellen. Erst die Kategorie wählen und dann alle anderen ...
Natürlich macht es Sinn die Produkteigenschaften dann auch dynamisch zu generieren. Sie hardcodiert im Quelltext festzuhalten macht absolut keinen Sinn.

2. Du musst gar nichts. Zugegeben ist die Rückgabe in JSON oder XML sinnvoll. Du könntest die Rückgabe mittles einer Template Engine aber auch schon als komplett zusammengestelltes Template liefern. JSON und XML bieten den riesigen Vorteil, dass sie universell einsetzbar sind. Du könntest sowohl JSON als auch XML mit Javascript parsen und daraus dann die Darstellung generieren.
Die Rückgabe an sich sollte nichts mit der Filterung zu tun haben. Grundsätzlich könntest Du auch mit Javascript filtern. Aber aus meiner Sicht macht es eher Sinn das Ergebnis bereits auf dem Server mit PHP vor der Rückgabe entsprechend zu filtern. Dies kannst Du, wie Du selbst schon sagtest, mit entsprechenden Where-Bedingungen in einem SQL Query erreichen, oder eben mit anderen Filter Techniken, wie z.B. mit dem oben erwähnten FilterIterator.

[schmidtsmikey]

So, ich bin jetzt einen Schritt weiter, da mich mir mal das bestehende DB-System angeschaut habe. Ist in weiten Teilen normalisiert und wichtige Informationen wie Formular-Typ und Werte erhalte ich aus der DB. Daraus kann ich die Formularfelder universell generieren.

Wegen XML/JSON: da lese ich mich noch ein. Notfalls geht es via Ajax und Where-Statements im SQL-Query.

Jetzt aber noch einmal eine Frage zum Datenbank-Design:

Was ist besser?

• Eine riesige Tabelle mit sehr vielen Spalten
• Viele Tabellen mit wenig Spalten

Nachteil bei 1. sehe ich darin, dass für jedes Produkt eine riesige Tabelle durchgesucht werden muss.
Nachteil bei 2. Liegt darin, dass MySQL für jede Tabelle neue Dateien anlegt, somit viele Datei-Handles entstehen.

Wir reden hier von ca. 400 Tabellen.

Zur Zeit wird pro Kategorie eine neue Tabelle erstellt, welche die Attribute beinhaltet. Handelt es sich beispielsweise um einen Fernseher, sucht man die passende Tabelle und findet dann sowas vor:

ProduktID    Attribut_1    Attribut_2    Attribut_4
123456        1           500           0
456789        0           1000          1
987654        1           1250          0
321321        0           10            0 

Ich bevorzuge die Aufteilung in eine Tabelle pro Attributgruppe. Meine Sorge liegt nur darin, wie MySQL mit 400 Tabellen klarkommt? Laut Doku gibt es Kunden mit 60.000 Tabellen. Aber laut dieser Anleitung verbraucht MySQL pro Tabelle zwei Dateihandles: http://dev.mysql.com/doc/refman/5.1/de/table-cache.html

Hat jemand dafür noch einen besseren Ansatz? Im Anhang habe ich noch mal das Datenbank-Design aufgezeichnet, wie es momentan vorliegt.