Всички те са функционално еквивалентни. Дори разделянето между клаузата WHERE и условието JOIN няма да промени резултатите, когато работите изцяло с INNER съединения (може да има значение при OUTER съединения). Освен това, всички те трябва да работят в абсолютно същия план на заявка (ефективно нулева разлика в производителността). Редът, в който включвате елементите, няма значение . Механизмът за заявки е свободен да оптимизира, тъй като смята, че се вписва най-добре във функционалната спецификация на заявката. Дори когато идентифицирате конкретно поведение по отношение на реда, не трябва да разчитате на него. Спецификацията позволява на утрешната корекция да промени днешното поведение в тази област. Запомнете:целият смисъл на SQL е да бъде базиран на множество и декларативен :казвате на базата данни какво искате да стане, а не как искате да го направи.
Сега, когато коректността и производителността са извън пътя, ние се спуснахме към въпроси на стила:неща като производителност на програмиста и четимост/поддържане на кода. В това отношение опция №4 в този списък е далече най-добрият избор, като номер 3 е следващият най-добър, особено когато започнете да навлизате в по-сложни заявки. Просто не използвайте A,B синтаксис вече; той е остарял от версията на SQL стандарта от 1992 г. Винаги изписвайте пълния INNER JOIN (или LEFT JOIN /RIGHT JOIN /CROSS JOIN и т.н.).
Всичко казано дотук, въпреки че редът няма (или поне би трябвало) да няма значение за производителността, намирам за полезно, когато пиша SQL, да използвам конвенция в моя подход, която диктува реда. Това ми помага да идентифицирам грешки или неверни предположения по-късно при отстраняване на грешки и отстраняване на неизправности. Това общо ръководство, което се опитвам да следвам, е да се държа така, сякаш редът има значение, и след това имайки това предвид, опитайте се да поддържате работния набор от памет, необходим на базата данни, за да изпълни заявката, възможно най-малък за възможно най-дълго време:започнете първо с по-малки маси и след това се присъединете към по-големите; когато обмисляте размера на таблицата, вземете предвид условията в клаузата WHERE, които съвпадат с индекс; предпочитайте вътрешните съединения пред външните, когато имате избор; избройте условията за присъединяване, за да облагодетелствате първо индексите (особено първичните/клъстерните ключове), а след това другите условия за присъединяването.
