[MySQL] JOIN of ID's gewoon gelijk stellen?

[Verwijderd]

Hallo, op http://www.w3schools.com/sql/sql_join_inner.asp staat een voorbeeld van een JOIN met MySQL.

Dit is de query en die kan je daar runnen om te zien wat eruit komt (196 resultaten):

SQL:

SELECT Customers.CustomerName, Orders.OrderID
FROM Customers
INNER JOIN Orders
ON Customers.CustomerID=Orders.CustomerID
ORDER BY Customers.CustomerName;

Nou kun je ook het volgende doen:

SQL:

SELECT Customers.CustomerName, Orders.OrderID
FROM Customers, Orders WHERE Customers.CustomerID=Orders.CustomerID
ORDER BY Customers.CustomerName;

En dan komt er hetzelfde uit. De 2e variant vind ik makkelijker te lezen als de queries wat langer worden. Maar is het wel slim om op deze manier te werken? Misschien is de 2e query zwaarder door het niet gebruiken van JOIN?

[NMe]

Dat levert allebei hetzelfde execution plan op voor zover ik weet, dus je kan expliciete (je eerste voorbeeld) en impliciete (je tweede voorbeeld) joins gewoon verwisselen zonder dat dat impact zou moeten hebben op je applicatie. Wel vinden de meeste mensen die ik ken juist die laatste manier van schrijven veel onhandiger lezen en bedenk je heel goed dat het bij die tweede variant makkelijker is om de join-conditie te vergeten waardoor je ineens een cross-join krijgt in plaats van een inner join. Ik zou me als ik jou was de eerste variant aanwennen.

Overigens is W3Schools traditioneel al niet zo'n heel goeie bron van informatie en voor SQL al helemaal niet. Ik weet niet wat tegenwoordig wel goed lesmateriaal is aangezien het alweer wat jaartjes geleden is dat ik de basis geleerd heb, maar W3Schools gebruiken is geen goed idee.

[deadinspace]

NMe schreef op woensdag 24 december 2014 @ 11:55:
Dat levert allebei hetzelfde execution plan op voor zover ik weet, dus je kan impliciete (je eerste voorbeeld) en expliciete (je tweede voorbeeld) joins ...

Volgensmij is de eerste juist expliciet en de tweede impliciet

Verwijderd schreef op woensdag 24 december 2014 @ 11:40:
SELECT Customers.CustomerName, Orders.OrderID ...

Tip: Het is voor ons leesbaarder als je SQL queries in [code=sql] ... [/code] blokken zet

[NMe]

deadinspace schreef op woensdag 24 december 2014 @ 12:03:
[...]

Volgensmij is de eerste juist expliciet en de tweede impliciet

Volgens mij heb je gelijk.

[Verwijderd]

Dank jullie, NMe en deadinspace. Duidelijk.

[roebfromthebloc]

Mij is altijd verteld dat JOIN sneller is dan WHERE.

Ik neem aan dat dit af zal hangen van de situatie. In dit geval zal de performance vrijwel gelijk zijn gezien de simpele query.

[NMe]

roebfromthebloc schreef op vrijdag 26 december 2014 @ 18:24:
Mij is altijd verteld dat JOIN sneller is dan WHERE.

Ik neem aan dat dit af zal hangen van de situatie. In dit geval zal de performance vrijwel gelijk zijn gezien de simpele query.

Je hebt gehoord en je neemt aan. Doe eens gewoon meten.

Even uit een van mijn eigen tabellen met een relatief laag (maar niet marginaal) aantal rijen:

SQL:

EXPLAIN SELECT Reservation.PlannedArrival, Occupant.LastName
FROM Reservation JOIN Occupant ON Reservation.OccupantId = Occupant.OccupantId
ORDER BY Occupant.LastName

id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
1	SIMPLE	Occupant	ALL	PRIMARY	NULL	NULL	NULL	16449	Using filesort
1	SIMPLE	Reservation	ref	CustomerId	CustomerId	5	database.Occupant.OccupantId	1	Using where

SQL:

EXPLAIN SELECT Reservation.PlannedArrival, Occupant.LastName
FROM Reservation, Occupant
WHERE Reservation.OccupantId = Occupant.OccupantId
ORDER BY Occupant.LastName

id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
1	SIMPLE	Occupant	ALL	PRIMARY	NULL	NULL	NULL	16449	Using filesort
1	SIMPLE	Reservation	ref	CustomerId	CustomerId	5	database.Occupant.OccupantId	1	Using where

Oftewel: hetzelfde execution plan.

[roebfromthebloc]

Interessant. Ik zal dit eens onderzoeken en met collega's overleggen.

Ben nu op vakantie, dus ga HELEMAAL niks doen ;D

[Verwijderd]

[Freeaqingme]

Ik zou jezelf de JOIN variant aanwennen. Niet vanwege performance, maar wel omdat wanneer je op een gegeven moment meerdere hebt, het geheel leesbaarder blijft. Dit omdat in het geval van een JOIN de tabelnamen en conditites bij elkaar staan, terwijl als je geen join gebruikt maar wel meerdere tabellen hebt, deze steeds verder uit elkaar staan.

Oh, en je hebt dan nog FULL/LEFT/RIGHT INNER/OUTER joins, met joins is dat makkelijker dan zonder

[The Eagle]

Ik snap je punt, maar een where werkt altijd, en voor joins hebben alle SQL dialecten een eigen implementatie. Bovendien: als jij met tooling aan de gang gaat die zelf joins legt zul je vaak zien dat ook daar de where's gemaakt worden, en niet het join commando. Van een where kun je namelijk vrij makkelijk een left of right outer join maken, ook op minder dan alleen alle sleutels. En das in tooling wel zo makkelijk

[NMe]

The Eagle schreef op zondag 28 december 2014 @ 17:06:
Ik snap je punt, maar een where werkt altijd, en voor joins hebben alle SQL dialecten een eigen implementatie.

He, wat? Onder water misschien, maar joins zijn toch echt onderdeel van de SQL-standaard en worden derhalve in elk DBMS dat ik ken mogelijk gemaakt met dezelfde syntax...

Bovendien: als jij met tooling aan de gang gaat die zelf joins legt zul je vaak zien dat ook daar de where's gemaakt worden, en niet het join commando. Van een where kun je namelijk vrij makkelijk een left of right outer join maken, ook op minder dan alleen alle sleutels. En das in tooling wel zo makkelijk

Waarom zou dat makkelijker zijn dan in de join-syntax? Om een inner join in een outer join te veranderen hoef ik alleen maar "(inner) join" te veranderen in "left/right/full join" en ik ben er. In een where moet je je conditie aanpassen naar "WHERE t1.id = t2.t1id OR t2.t1id IS NULL" of iets dergelijks. Waarom zou wat voor tooling dan ook moeite hebben met een makkelijkere syntax? Nog naast het feit dat hierboven al aangedragen wordt: je trekt je join en je joinconditie uit elkaar in de impliciete join-syntax waardoor je query al bij 3 joins lastig te doorgronden wordt.

[Freeaqingme]

> Voor joins hebben alle SQL dialecten een eigen implementatie.

Dat lijkt me sterk. Joins zijn gewoon onderdeel van de ANSI SQL standaard. Tuurlijk zitten er tussen de implementaties van diverse RBMS'en altijd wel minieme implementatieverschillen, maar dat geldt voor alle SQL, niet specifiek voor JOIN-clauses. En je programmeert meestal voor 1 RDBMS (dit topic ging specifiek over MySQL), of je hebt een DBAL die de implementatieverschillen abstraheert.

Verder is het natuurlijk prima als iets als een ORM je queries construeert met WHERE clauses, maar ook dan zou ik zeggen dat in je code - waar je die tooling aanspreekt - je ook de tabelnamen en condities bij elkaar wilt houden.

Edit: Typo. Verder sluit ik me graag bij NME aan.

[ Voor 14% gewijzigd door Freeaqingme op 28-12-2014 17:27 ]

[Verwijderd]

> Voor joins hebben alle SQL dialecten een eigen implementatie.

Ja, ik denk dat dat komt door dingen zoals dat INNER JOIN hetzelfde is als JOIN. En dat in sommige databases RIGHT JOIN hetzelfde is als RIGHT OUTER JOIN in andere databases. En dat je voor LEFT JOIN dan LEFT OUTER JOIN kan gebruiken. Is dat misschien wat bedoeld wordt?

Ik dacht zelf eerst 'Waarom moeilijk doen als het makkelijk kan? En dan gewoon een WHERE t1.x=t2.y gebruiken. Maar ik zie natuurlijk ook in dat dat voor ingewikkelde queries wat moeilijker te lezen zal zijn dan voor eenvoudige queries.

Sowieso wel weer leerzaam dit!

[NMe]

Verwijderd schreef op zondag 28 december 2014 @ 18:12:
Ja, ik denk dat dat komt door dingen zoals dat INNER JOIN hetzelfde is als JOIN. En dat in sommige databases RIGHT JOIN hetzelfde is als RIGHT OUTER JOIN in andere databases. En dat je voor LEFT JOIN dan LEFT OUTER JOIN kan gebruiken. Is dat misschien wat bedoeld wordt?

Dat komt omdat je, ook volgens de standaard, "INNER" mag weglaten omdat een join tenzij anders aangegeven altijd een inner join is. Hetzelfde geldt voor outer joins: je mag die "OUTER" weglaten omdat LEFT en RIGHT al impliceren dat het een outer join is; een left inner join bestaat niet.