[SQL] FROM , Where Query naar JOIN

[emkedouwe]

Hey, ik heb de volgende db:

Tabel Klant
- Klant_id
- Klant_naam

Tabel Member
- Member_id
- Klant_id

Tabel Reservering
- Member_id
- Product_id

Tabel Product
- Product_id
- Product_naam

Nou wil ik een query maken die per klant een overzicht genereerd van de gebruikte producten, dus:
Klant_naam | Product_naam | Count(aantal keer product naam)

Ik heb zelf het volgende bedacht:

code:

SELECT klant.klant_naam, product.product_naam, COUNT(product.product_naam) 
FROM klant, member, reservering, product 
WHERE member.klant_id = klant.klant_id AND reservering.member_id = member.member_id 
AND reservering.product_id = product.product_id 
AND RESERVERING_BEGINDATUM >'2003-01-01' AND RESERVERING_EINDDATUM <'2004-01-01' 
GROUP BY klant.klant_naam

Maar als uitvoer krijg ik:

KLM Internet 2

En dit moet zijn:

KLM Internet 2
KLM telefoon 1
Philips Internet 1

Wie weet de oplossing. De DB is in MySQL

[momania]

Als je eerst eens begint om de tijden buiten je query te laten en stap voor stap een kolom toevoegen aan je resultaat. Dan moet je d'r heel goed uitkomen.
Selecteer dus eerst alleen klant + product en group dat by product. Dan heb je alle klanten + al hun producten.
Je joined dus dan producten klant middels:
FROM klant JOIN product ON poduct.klant_id = klant.klant_id

Daarna doe je de count voor de pruducten erbij, etc etc.


_{Voor datum vergelijkingingen kan je ook het BETWEEN keyword gebruiken}

[ Voor 8% gewijzigd door momania op 18-06-2003 17:10 ]

[emkedouwe]

Zou iemand me uit kunnen leggen hoe ik twee joins doe ??

want ik moet:
klant->member->reservering->product

Dus ik heb drie joins nodig

[Yo-han]

emkedouwe schreef op 18 June 2003 @ 17:17:
Zou iemand me uit kunnen leggen hoe ik twee joins doe ??

want ik moet:
klant->member->reservering->product

Dus ik heb drie joins nodig

code:

FROM klant LEFT JOIN members ON ......... 
LEFT JOIN producten ON .......

is het niet gewoon makkelijker om bij je tabel reserveringen even een extra kolom klant_id te zetten? Maakt je query makkelijker en sneller volgens mij....
Wordt member zelfs overbodig

[ Voor 29% gewijzigd door Yo-han op 18-06-2003 17:26 ]

[emkedouwe]

heb nu:

code:

SELECT klant.klant_naam, reservering.product_id, product.product_naam
FROM ((klant INNER JOIN member ON klant.klant_id = member.klant_id) INNER JOIN reservering ON member.member_id = reservering.member_id) INNER JOIN product ON reservering.product_id = product.product_id
GROUP BY klant.klant_naam, reservering.product_id, product.product_id

Nu de count nog, ik kan het wel

[Yo-han]

Is het niet slimmer of bij sommige tabellen een RIGHT of LEFT JOIN toe te passen. Bedenk wel dat een join het aantal rijen vermenigvuldigd.

Dus 100 rijen in de ene tabel en 250 in de andere levert een al een mooi resultaat op ...

Kan beter zorgen voor 1 uit de ene tabel (klant_id of member_id) en daarme met een LEFT o RIGHT join de andere tabel doorspitten. 1 x 250 is dan toch weer sneller!

[robjanssen]

code:

SELECT klant.klant_naam, P.product_naam, COUNT(P.product_naam) 
FROM klant K
INNER JOIN member M ON K.klant_id = M.klant_id
INNER JOIN reservering R ON M.member_id = R.member_id 
INNER JOIN product P ON R.product_id = P.product_id
WHERE R.RESERVERING_BEGINDATUM BETWEEN '2003-01-01' AND '2004-01-01' 
GROUP BY K.klant_naam, P.product_naam

[whoami]

dayoman schreef op 18 June 2003 @ 17:39:
Is het niet slimmer of bij sommige tabellen een RIGHT of LEFT JOIN toe te passen.

Als je geen LEFT of RIGHT (OUTER dus) join nodig hebt, dan moet je dat ook niet doen. Een OUTER join is alleen maar trager dan een gewone INNER join, en gebruik je dus beter niet als je het echt niet nodig hebt.

Bedenk wel dat een join het aantal rijen vermenigvuldigd.

Dus 100 rijen in de ene tabel en 250 in de andere levert een al een mooi resultaat op ...

Het niet joinen bedoel je?
Niet joinen van de tabellen in je FROM clause levert een cartesisch produkt.

[Yo-han]

whoami schreef op 18 juni 2003 @ 20:14:
[...]
Als je geen LEFT of RIGHT (OUTER dus) join nodig hebt, dan moet je dat ook niet doen. Een OUTER join is alleen maar trager dan een gewone INNER join, en gebruik je dus beter niet als je het echt niet nodig hebt.
[...]

Het niet joinen bedoel je?
Niet joinen van de tabellen in je FROM clause levert een cartesisch produkt.

...? Ik heb toch echt geleerd dat ook bij een bepaalde JOIN je rijen worden vermenigvuldigd. Toch eens even nakijken dan...

[Verwijderd]

dayoman schreef op 19 June 2003 @ 09:47:

...? Ik heb toch echt geleerd dat ook bij een bepaalde JOIN je rijen worden vermenigvuldigd. Toch eens even nakijken dan...

D-uh, als je geen indexes of primary/foreign keys gebruikt krijg je inderdaad een cartesische vergelijking tussen de tabellen, die daarna gefilterd wordt op je join-conditie. Dan staat ie wel even te grazen ja!
Maar in een moderne database ga je op row-id je jointabel in en is het resultaat vliegensvlug

[whoami]

Verwijderd schreef op 19 June 2003 @ 10:11:
[...]


D-uh, als je geen indexes of primary/foreign keys gebruikt krijg je inderdaad een cartesische vergelijking tussen de tabellen, die daarna gefilterd wordt op je join-conditie. Dan staat ie wel even te grazen ja!

Jij hebt het hier over table-scans. Ik denk dat dayoman het heeft over resultsets die een cartesiaans product zijn.

Maar in een moderne database ga je op row-id je jointabel in en is het resultaat vliegensvlug

Hoe ga jij joinen op rowid ? Imho veel meer werk en onduidelijker dan gewoon joinen op PK/FK, wat trouwens niet veel trager zal zijn.

[Verwijderd]

whoami schreef op 19 June 2003 @ 10:15:
[...]


Jij hebt het hier over table-scans. Ik denk dat dayoman het heeft over resultsets die een cartesiaans product zijn.

Ik had de indruk dat er een spraakverwarring hier was, vandaar.

[...]
Hoe ga jij joinen op rowid ? Imho veel meer werk en onduidelijker dan gewoon joinen op PK/FK, wat trouwens niet veel trager zal zijn.

Ik join niet op rowid. Maar als je een index hebt pikt ie de rowid bij de FK-waarde en gaat daarmee alsnog de tabel in. Dus onder water zal je heel vaak wel op row-id zoeken in de database.
Als jij droog op FK de tabel in gaat, doe je alsnog een full table scan want dan heb je blijkbaar geen index. Klein verschil, maar heel belangrijk.

[whoami]

Verwijderd schreef op 19 June 2003 @ 11:18:
[...]

Als jij droog op FK de tabel in gaat, doe je alsnog een full table scan want dan heb je blijkbaar geen index. Klein verschil, maar heel belangrijk.

Idd, ik was hier niet volledig. Ik leg op m'n foreign keys echter altijd een index. Vandaar.

[Verwijderd]

whoami schreef op 19 June 2003 @ 11:19:

Idd, ik was hier niet volledig. Ik leg op m'n foreign keys echter altijd een index. Vandaar.

Op zich goed dat dat al zo'n routine is dat je het niet meer in de gaten hebt

Zit me nu even af te vragen of Oracle ook de FK automatisch indexeert als je een relatie aanlegt. De PK ben ik wel zeker van. Strax eens ff nakijken.