To je velmi krátkozraké uvažování při návrhu selectu.
Racchek může ve své práci potřebovat následně vyselektovat třeba opak. Pokud to udělá OUTER JOINEM, jen vymění podmínku - což se hodí zejména ve scriptech.
Proto tvrdím, že pokud někdo navrhuje dotaz, měl by ho udělat co nejuniverzálnější. Následně se dá takový dotaz uložit jako VIEW a pak už vstoupí do hry jen to samotné WHERE.
Tohle je ukázkový příklad antipatternu „předčasná optimalizace“. Kód má být především správný, pak přehledný, srozumitelný a udržovatelný. Což v tomto případě znamená INNER JOIN, protože u něj to každý vidí na první pohled, že jde o INNER JOIN.
Navíc jste si bůhví proč vybral jako možnou modifikaci vybral zrovna ten jeden (nepravděpodobný) dotaz. Vzhledem k tomu, že v případě jediného zatím požadovaného dotazu je tam INNER JOIN, dá se předpokládat, že i případný „opačný“ dotaz bude zase INNER JOIN. Protože ty záznamy, pro které neexistuje podřízený záznam, jsou při spojení určitým způsobem nezajímavé, a budou nezajímavé pořád, ať se na ně díváte zleva nebo zprava. Takže v případě vytváření dalších dotazů tam pořád bude nutné přidávat tu podmínku pro INNER JOIN, pořád na to bude muset někdo myslet a hrozí, že ji přidá špatně. I pro další práci je tedy lepší mít ten INNER JOIN, protože tam je spojení tabulek pěkně definováno přímo u JOINu a do WHERE už se píšou jenom podmínky filtrující výslednou sadu. A pokud někdo náhodou bude potřebovat něco speciálního a tedy použít OUTER JOIN, holt si ten jeden příkaz napíše. Ostatně proto je zase vhodná syntaxe JOINu, kdy prostě jenom před klíčové slovo JOIN napíše LEFT nebo RIGHT a nemusí hledat mezi podmínkami ve WHERE, kde že je ta JOINovací podmínka vložená.