MULTI distinct
Ik heb een tabel product details waarvan ik selectie tool wil maken . Hiervoor zou ik per rij de unieke gegevens willen uithalen met 1 query maar het lukt met niet.
KbId Gamma Lengte Breedte Diepte Dekselbreedte Dekselincl Materiaal
Bv bij lengte staat 2100 en 2000 dus zou deze 2 mogelijkheden moeten weergeven.
Met een distinct en group by zit ik vast aangezien deze niet per rij het unieke weergeeft.
Is het beter van de details in een aparte tabel te steken?
bv
Tabel Lengte
Tabel Breedte
Tabel Diepte
enz. Op deze manier kan ik een join maken maar dit lijkt me enorm omslachtig.
Graag feedback
KbId Gamma Lengte Breedte Diepte Dekselbreedte Dekselincl Materiaal
Bv bij lengte staat 2100 en 2000 dus zou deze 2 mogelijkheden moeten weergeven.
Met een distinct en group by zit ik vast aangezien deze niet per rij het unieke weergeeft.
Is het beter van de details in een aparte tabel te steken?
bv
Tabel Lengte
Tabel Breedte
Tabel Diepte
enz. Op deze manier kan ik een join maken maar dit lijkt me enorm omslachtig.
Graag feedback
Het probleem waar je mee zou kunnen komen te zitten is het volgende:
stel je hebt deze producten:
en stel ik selecteer eerst een breedte van 25cm en vervolgens een lengte van 350cm. Die bestaat dan dus niet!
Dat wil zeggen er bestaan wel planken van 25cm breedte en ook wel planken van 350cm maar net de combinatie van die twee niet...
Hoe wil je dit oplossen?
Je kunt kiezen voor een AJAX oplossing waarin de inhoud van de tweede selectbox wordt aangepast aan de hand van de keuze die gemaakt wordt in de eerste selectbox.
Verder is het vooral je query opbouwen en vooral in de WHERE clause.
SELECT * FROM products WHERE breedte=25 AND lengte=350
stel je hebt deze producten:
Code (php)
1
2
3
4
5
2
3
4
5
materiaal breedte lengte
------------------------
plank 25 270
plank2 30 350
plank3 30 270
------------------------
plank 25 270
plank2 30 350
plank3 30 270
en stel ik selecteer eerst een breedte van 25cm en vervolgens een lengte van 350cm. Die bestaat dan dus niet!
Dat wil zeggen er bestaan wel planken van 25cm breedte en ook wel planken van 350cm maar net de combinatie van die twee niet...
Hoe wil je dit oplossen?
Je kunt kiezen voor een AJAX oplossing waarin de inhoud van de tweede selectbox wordt aangepast aan de hand van de keuze die gemaakt wordt in de eerste selectbox.
Verder is het vooral je query opbouwen en vooral in de WHERE clause.
SELECT * FROM products WHERE breedte=25 AND lengte=350
Gewijzigd op 04/06/2017 20:36:54 door Frank Nietbelangrijk
Frank al bedankt voor de reactie.
Dit is inderdaad het probleem dat ik tegenkom. Nu geeft hij me in mijn menu 3 waarden weer vanwege hetgeen u beschrijft.
Hetgeen ik wou vermijden is de where clause, aangezien deze een vertraging oplevert in je database.Daar mysql gebruik gaat maken van filesort.Vandaar dat ik php het denkwerk wil laten doen bij het afhandelen van de gevraagde data. Wat ik wil bereiken is hetgeen dat coolblue.be hanteert bij hun keuzehulp menu. Zou dit probleem kunnen opgelost worden met multi array en een array_unique ? For each array array unique...
Dit is inderdaad het probleem dat ik tegenkom. Nu geeft hij me in mijn menu 3 waarden weer vanwege hetgeen u beschrijft.
Hetgeen ik wou vermijden is de where clause, aangezien deze een vertraging oplevert in je database.Daar mysql gebruik gaat maken van filesort.Vandaar dat ik php het denkwerk wil laten doen bij het afhandelen van de gevraagde data. Wat ik wil bereiken is hetgeen dat coolblue.be hanteert bij hun keuzehulp menu. Zou dit probleem kunnen opgelost worden met multi array en een array_unique ? For each array array unique...
>> Hetgeen ik wou vermijden is de where clause, aangezien deze een vertraging oplevert in je database.Daar mysql gebruik gaat maken van filesort.Vandaar dat ik php het denkwerk wil laten doen bij het afhandelen van de gevraagde data
Ik weet niet of ik moet lachen of huilen hierom. Je database zal in dit soort gevallen ALTIJD sneller zijn dan PHP. Het enige dat nodig is, is het opzetten van een handige structuur, handige queries en handige indexes. Waarom zou je denken dat PHP dat sneller kan?
Ik weet niet of ik moet lachen of huilen hierom. Je database zal in dit soort gevallen ALTIJD sneller zijn dan PHP. Het enige dat nodig is, is het opzetten van een handige structuur, handige queries en handige indexes. Waarom zou je denken dat PHP dat sneller kan?
Ik ben eens met Ben van Velzen. Dit is nu precies WAAROM je een database wilt gebruiken:
Snel de informatie verkrijgen die je nodig hebt.
Voorzie de kolommen waarop je (veel) moet filteren gewoon van een index.
Snel de informatie verkrijgen die je nodig hebt.
Voorzie de kolommen waarop je (veel) moet filteren gewoon van een index.
Frank, Ben,
De kolommen waarop veel gefilterd moet worden zijn reeds voorzien van een index.Voor het onderwerp Filesort wil ik verwijzen om deze discussie voort te zetten in de koffiehoek .Echter blijf ik met hetzelfde probleem zitten. Mocht ik een oplossing gevonden hebben zal ik deze ook posten. Alvast bedankt.
De kolommen waarop veel gefilterd moet worden zijn reeds voorzien van een index.Voor het onderwerp Filesort wil ik verwijzen om deze discussie voort te zetten in de koffiehoek .Echter blijf ik met hetzelfde probleem zitten. Mocht ik een oplossing gevonden hebben zal ik deze ook posten. Alvast bedankt.
Voor het onderwerp filesort wil ik je hiernaar verwijzen: https://www.percona.com/blog/2009/03/05/what-does-using-filesort-mean-in-mysql/ Filesort is namelijk helemaal niet slecht, de gevraagde sorteervolgorde is gewoon niet hetzelfde als die van de gebruikte index.




