Nejspíš jste si ještě nevšimnul že SQL je deklarativní jazyk, takže to jak zapíšete dotaz nemá přímý vliv na to jak ho databáze provede - volba execution planu v databázi je celkem komplikovaná věc, takže tvrdit že ten korelovaný poddotaz bude databáze provádět jinak (a dokonce náročněji) než ty joiny podle mě je naprosto nepodložená spekulace.
Nejspis sis jeste nevsim, jak SQL v realite funguje. Kupodivu i velmi drobna zmena zapisu ma zcela zasadni vliv na vykon a rychlost dotazu.
SQL používám k obživě už od dob kdy u Oracle vydali verzi databáze 8.0 jako novinku, takže si myslím že jsem si za tu dobu už stačil všimnout jak SQL v realitě funguje. Dovolte mi tedy opravit vaše chybné tvrzení, správně to má znít "Kupodivu i velmi drobna zmena zapisu může mít zcela zasadni vliv na vykon a rychlost dotazu." - nikde totiž není záruka že změna v zápisu dotazu skutečně bude mít vliv na výkon a rychlost dotazu, ba právě naopak: databáze se i přepsaný dotaz může rozhodnout vykonat přesně stejně jako ten původní, viz příklad níže.
Subselect je pak v 90% zdaleka nejhorsi mozna varianta vubec.
To záleží na konkrétní databázi. Například u Oracle jsou tyto dva dotazy prováděny naprosto stejně, za předpokladu že sloupec b v tabulce b je nut null:
select a.a from a where a.a not in (select b.b from b);
select a.a from a where not exists (select 1 from b where a.a=b.b);
Maly (zcela realny) priklad. M$SQL (jedno jake verze). cosi is null vs isnull(cosi,0) = 0. Druha varianta je asi tak 100x rychlejsi. Divne co? Dtto prozmenu pouziti datediff() je asi tak 1000x pomalejsi, nez proste odecitani/scitani. Nekdy o tom, jestli dotaz vubec dobehne, rozhoduje i poradi.
Prosím nezobecňuje chování všech SQL databází podle jedné implementace, navíc zrovna takové hodně špatné. Microsoft SQL je jen hračka dobrá nanejvýš pro zpracování malých dat, i když uznávám že to verzi od verze celkem dost zlepšují - ke špičkovým databázím mají ale ještě daleko.