[SQL] optimal joins

[Punkie]

Inner joins & cross joins kan je altijd herschrijven (al dan niet zonder WHERE) als
FROM a , j
WHERE a.fp = j.pk

Zijn inner joins & cross joins dan niet meer dan syntactic sugar? Is het gebruik van USING en ON identiek aan WHERE inzake verwerkingssnelheid?

[430xlkod]

Zoek het even op? Weet niet als hier je antwoord in voorkomt maar er staat toch al redelijk wat uitleg in: http://www.sql-server-performance.com/2006/tuning-joins/.

[ Voor 5% gewijzigd door 430xlkod op 15-12-2011 10:13 ]

[Big Womly]

Als je Query optimizer goed werkt zou dit exact hetzelfde execution plan moeten opleveren.
Het JOIN statement is wel eens zo lekker leesbaar omdat je de link legt via de ON clausule en het effectief filteren van je resultaten in de WHERE.

Google maar eens op performance join vs where

[TheNephilim]

Op het moment dat je meerdere joins krijgt, is het zeker een stuk leesbaarder om gewoon INNER JOIN ... te gebruiken. Ik vind het zelf ook altijd prettig om de echte WHERE dingen gescheiden te houden van de ON of USING in joins.

[Punkie]

Met googel krijg je alle mogelijke antwoorden, inclusief mensen die het omgekeerde denken (vb http://www.bennadel.com/b...lause-vs-WHERE-Clause.htm vs http://stackoverflow.com/...21631/inner-join-vs-where)

Naar mijn gevoel is JOIN in de meeste gevallen syntactic sugar en is het dus identiek nog voor het geoptimaliseerd wordt.

[Woy]

Punkie schreef op donderdag 15 december 2011 @ 10:54:
Naar mijn gevoel is JOIN in de meeste gevallen syntactic sugar en is het dus identiek nog voor het geoptimaliseerd wordt.

Dat is wel een goede vuistregel, maar zou per DB engine kunnen verschillen. Ik zou in ieder gewoon altijd de JOIN syntax gebruiken omdat dat veel leesbaarder is, en mocht je bij een of andere crappy DB systeem een perfomance probleem tegen komen kun je altijd nog kijken of je er toch voor kiest om het op de andere manier te doen ( Al verwacht ik niet dat er veel DB systemen zijn die de verschillende notaties anders behandelen ).

Maar als je het graag zeker wil weten is het natuurlijk erg eenvoudig om beide query's eens in je DB engine te gooien en te kijken wat de execution plans zijn.

[ Voor 10% gewijzigd door Woy op 15-12-2011 11:14 ]

[Killemov]

Punkie schreef op donderdag 15 december 2011 @ 10:54:
Naar mijn gevoel is JOIN in de meeste gevallen syntactic sugar en is het dus identiek nog voor het geoptimaliseerd wordt.

Ik ben het met je eens dat het in veel gevallen alleen maar om syntactic sugar gaat. En dan is het toch nog nuttig omdat het beter leesbaar zou zijn en handig is om later ook nog even eenvoudig te kunnen switchen naar een outer variant. Dat ga je toch wel merken bij grote queries.

[Remus]

Punkie schreef op donderdag 15 december 2011 @ 10:05:
Inner joins & cross joins kan je altijd herschrijven (al dan niet zonder WHERE) als
FROM a , j
WHERE a.fp = j.pk

Zijn inner joins & cross joins dan niet meer dan syntactic sugar? Is het gebruik van USING en ON identiek aan WHERE inzake verwerkingssnelheid?

Eigenlijk is dit enkel de syntax voor het carthesisch product van alle tables met daarna in de WHERE je filter voorwaarden. De query optimizer verandert het echter in bijvoorbeeld een INNER JOIN, omdat dat vele male efficienter is dan eerst een carthesisch product opbouwen en daarna het grootste deel weer weg te gooien.

Het voordeel van de expliciete join syntax is dat het duidelijker is hoe je je query opbouwt, het is makkelijker om te switchen tussen join type en je voorwaarden in de WHERE zijn beperkt tot de filterende voorwaarden (iaw: een duidelijker scheiding tussen de diverse taken).

Ik zie eigenlijk geen reden waarom je *wel* deze syntax zou gebruiken

[cariolive23]

Remus schreef op zaterdag 17 december 2011 @ 17:23:
[...]

Eigenlijk is dit enkel de syntax voor het carthesisch product van alle tables met daarna in de WHERE je filter voorwaarden. De query optimizer verandert het echter in bijvoorbeeld een INNER JOIN, omdat dat vele male efficienter is dan eerst een carthesisch product opbouwen en daarna het grootste deel weer weg te gooien.

Dat is niet meer dan een aanname en geldt in elk geval niet voor PostgreSQL: PostgreSQL zal intern een INNER JOIN herschrijven naar een WHERE en vervolgens voor ieder onderdeel van de query het meest ideale queryplan gaan berekenen. De functie eqjoinsel() is verantwoordelijk voor de "join" en daar is er maar één van.

Meer informatie hierover kun je vinden in de handleiding:

• Genetic Query Optimizer
• How the Planner Uses Statistics

Het voordeel van de expliciete join syntax is dat het duidelijker is hoe je je query opbouwt, het is makkelijker om te switchen tussen join type en je voorwaarden in de WHERE zijn beperkt tot de filterende voorwaarden (iaw: een duidelijker scheiding tussen de diverse taken).

+1

Hoewel filterende voorwaarden ook in de JOIN conditie kunnen worden opgenomen, en het in sommige gevallen zelfs noodzakelijk is om een correct resultaat retour te krijgen. Al speelt dat laatste niet bij INNER JOIN's.

SQL is een taal om met de database te communiceren, niet een taal om de database te vertellen hoe iets moet worden opgezocht. Dat laatste mag de database zelf uitzoeken, de database heeft veel meer informatie over de data dan dat ik dat kan hebben. Mits goed ingericht en onderhouden...

Ps. EXPLAIN laat in PostgreSQL ook zien hoe een query wordt herschreven, met die informatie kun je jouw eigen brouwsel van complexe queries vaak ook al een heel stuk verbeteren in de leesbaarheid.