Al deze zijn functioneel equivalent. Zelfs de scheiding tussen de WHERE-clausule en de JOIN-voorwaarde zal de resultaten niet veranderen wanneer u volledig met INNER-joins werkt (het kan van belang zijn met OUTER-joins). Bovendien zouden deze allemaal in exact hetzelfde queryplan moeten uitwerken (in feite nul prestatieverschil). De volgorde waarin u items opneemt maakt niet uit . De query-engine is vrij te optimaliseren naar eigen inzicht binnen de functionele specificatie van de query. Zelfs als u specifiek gedrag met betrekking tot bestellen identificeert, moet u er niet op rekenen. De specificatie zorgt ervoor dat de patch van morgen het gedrag van vandaag op dit gebied kan veranderen. Onthoud:het hele punt van SQL moet set-gebaseerd zijn en declaratief :je vertelt de database wat je wilt dat het doet, niet hoe je wilt dat het het doet.
Nu correctheid en prestaties niet meer in de weg staan, moeten we ons bezighouden met stijlkwesties:zaken als productiviteit van programmeurs en leesbaarheid/onderhoudbaarheid van de code. In dat opzicht is optie #4 in die lijst veruit de beste keuze, met #3 de op één na beste, vooral als je meer gecompliceerde vragen begint te krijgen. Gebruik gewoon niet de A,B syntaxis meer; het is achterhaald sinds de 1992-versie van de SQL-standaard. Schrijf altijd de volledige INNER JOIN (of LEFT JOIN /RIGHT JOIN /CROSS JOIN enz.).
Dat gezegd hebbende, hoewel volgorde er niet toe doet (of in ieder geval zou moeten) voor de prestaties, vind ik het wel handig als ik SQL schrijf om een conventie in mijn aanpak te gebruiken die de volgorde wel dicteert. Dit helpt me later fouten of valse aannames te identificeren bij het debuggen en oplossen van problemen. Deze algemene gids die ik probeer te volgen, is om te doen alsof de volgorde er toe doet, en probeer met dat in gedachten de werkset geheugen die de database nodig heeft om de query zo lang mogelijk te vervullen, zo klein mogelijk te houden:begin eerst met kleinere tabellen en sluit u vervolgens aan bij de grotere; houd bij het overwegen van de tabelgrootte rekening met voorwaarden in de WHERE-clausule die overeenkomen met een index; geef de voorkeur aan de binnenste naden voor de buitenste als je de keuze hebt; lijst join-voorwaarden op om de voorkeur te geven aan indexen (vooral primaire/geclusterde sleutels) eerst en andere voorwaarden aan de join als tweede.