Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien
Toon posts:

[PHP] Producten filter op basis van checkboxen

Pagina: 1
Acties:

Onderwerpen


Verwijderd

Topicstarter
Momenteel ben ik bezig met het maken van een filter functie waarmee mensen op eenvoudige wijze kunnen bepalen welke producten ze willen zien. Hoe meer vinkjes ze aanzetten hoe meer of minder producten er verschijnen.

Zie voorbeeld: Afbeeldingslocatie: http://img685.imageshack.us/img685/6218/filterh.jpg
edit: Hmm, afbeelding inladen werkt niet. Oproepen middels browser wel.

Nu werkt het tonen van producten prima. Wanneer ik "Artstone" en "Elho" aanvink worden netjes de producten getoond die zijn gekoppeld aan deze metadata velden. Wanneer ik vervolgens ook "Kunstof" aan vink worden er drie producten getoond die aan Artstone of Elho zijn gekoppeld maar ook aan Kunstof. De rubrieken (Mrken / Materiaal / Vormen) zijn dus onderling AND'S en de velden daaronder (Artstone / Elho / etc.) OR'S.

Nu wil ik ook dat wanneer een klant bijv. Arstone heeft aangeklikt dat de cijfers achter de verschillende rijen geüpdate worden zodat je direct kan zien dat de Elho producten bijv. wel in Kunsstof zijn maar niet in Terrasso.

Dit krijg ik echter niet voor elkaar.

Mijn database structuur

TABEL: product
TABEL: tree -> hier staan de rubrieken in zoals Merken - Materiaal - Vormen
TABEL: product_metadata -> hier staan de velden zoals Artstone / Elho etc..) in
TABEL: _rel_product_metadata -> hier zit de koppeling tussen het product en het metadata veld

Een product krijgt dus meerdere metadata velden toegewezen. In dit voorbeeld: Merken / Materiaal / Vorm.

Voor het produceren van de tree in de afbeelding gebruik ik de volgende query:

SQL:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
SELECT      
                product.id AS product_id,  
                tree.id AS tree_id,
                tree.name AS tree_name,
                product_metadata.id,
                product_metadata.title,
                COUNT(_rel_product_metadata.product_id) AS amount
            FROM
                tree
                    INNER JOIN
                product_metadata
                    ON
                        product_metadata.tree_id = tree.id
                    INNER JOIN
                _rel_product_metadata 
                    ON
                        _rel_product_metadata.product_metadata_id = product_metadata.id                 
                    INNER JOIN
                product
                    ON
                        product.id = _rel_product_metadata.product_id
                            AND
                        product.online = 1                          
            GROUP BY
                tree.id,
                product_metadata.id
            ORDER BY  
                tree.prio,
                product_metadata.prio


Heb verschillende dingen geprobeerd; voor elke waarde een JOIN toevoegen en dan een beperking opleggen met IN, maar door de JOINS gaat de COUNT de mist in...

Wie kan mij hiermee uit de brand helpen?

[ Voor 1% gewijzigd door RobIII op 21-09-2011 22:54 . Reden: afbeelding gefixed... ]


Verwijderd

Je hebt nu in elk geval aangetoond dat je database kennelijk niet zo goed in elkaar steekt. Volgens mij moet je het probleem eerder in je databaseontwerp zoeken dan in je query.

Verwijderd

Topicstarter
Volgens mij zit mijn database wel goed in elkaar. Koppeling zit netjes in een aparte tabel en volgens mij is dit volgens de normalisatie regels een juist ontwerp. Of zie jij dat anders? Hoe zou jij een DB ontwerp als deze dan in elkaar zetten?

  • Ramon
  • Registratie: Juli 2000
  • Laatst online: 09:39
Dit probleem kan je heel makkelijk oplossen door gebruik te maken van Solr en de facets die je daarmee kan gebruiken. Solr maakt dan zelf zo een 'tree' voor je met de bijbehorende counts. Zie http://wiki.apache.org/solr/SolrFacetingOverview

Check mijn V&A ads: https://tweakers.net/aanbod/user/9258/


Verwijderd

Topicstarter
Oké, maar dat zou betekenen dat ik ook door SOLR moet laten indexeren? Is er geen eenvoudigere mogelijkheid om dit gewoon met Mysql i.c.m. PHP te realiseren? Dit betreft namelijk extra functionaliteit boven mijn standaard website en om SOLR dan alleen voor deze functionaliteit te moeten inzetten zie ik niet echt zitten of valt dat wel mee?

  • creator1988
  • Registratie: Januari 2007
  • Laatst online: 26-11 21:19
Kan best, maar wordt een takkewerk. Coding Glamour: Solr, deel 1: Introductie tot faceted search. Oude en nieuwe situatie bij funda.

[ Voor 8% gewijzigd door creator1988 op 22-09-2011 15:38 ]


Verwijderd

Topicstarter
Goed artikel, maar het wordt wel inderdaad wel een enorm werk. Ten eerste zal Solr geconfigureerd moeten waarna vervolgens alles geïndexeerd moet gaan worden door Solr. Daarna moet de applicatie omgebouwd worden zodat die kan communiceren met Solr en dat zal ook nog niet meevallen.

Omdat het hier niet om een website als funda gaat wat verkeer betreft zou ik het toch graag met MySQL willen proberen. Heb ook al gezocht op faceted MySQL, maar ik kan helaas niks nuttigs vinden.

[ Voor 66% gewijzigd door Verwijderd op 22-09-2011 16:24 ]


  • moozzuzz
  • Registratie: Januari 2005
  • Niet online
1. Ik zie het nut van tree en metadata als twee aparte tabellen, niet.
Nu wil ik ook dat wanneer een klant bijv. Arstone heeft aangeklikt dat de cijfers achter de verschillende rijen geüpdate worden zodat je direct kan zien dat de ElhoArstone producten bijv. wel in ....
2. mi moet je je basisquery gewoon aanvullen met een WHERE metadata=Arstone en dat resultaat dan mergen met de basisquery.

Verwijderd

Topicstarter
1) Dat hoeft in principe ook niet omdat je binnen de metadata tabel ook met bijv. parent_id zou kunnen werken voor het onderverdelen van de rubrieken, maar binnen het CMS wordt het voor mij afgedwongen om ook de tabel tree te gebruiken en dat is ook geen enkel probleem. Kost slechts 1 extra join

2) Probleem heb ik opgelost door verschillende subqueries die verschillende zaken controleren. Het filter werkt nu perfect!

Dank voor de reacties.
Pagina: 1