Spousta lidí to neví, ale pravda je taková, že typicky* nezáleží na tom jak je to napsané, optimalizátor to udělá pořád stejně. Existují sice lidé, kteří na přepisy věří - ale typický přepis implicitně přidá/odstraní nějakou novou informaci pro optimalizátor (například když neudělam join ale dam to do projection jako skalární select muže to vracet stejný výsledek ale dal jsem sql enginu navíc informaci, že pro každý řádek z jedné tabulky muže být jen jeden z druhé, kterou při joinu mít nemusel = tzn stejný výsledek ale nejsou to stejné selecty).

Pokud tam máš primární klíče na id, a zakaznik_id a tedy i (heh dnes jsem na to zrovna narazil s JaFim a myslim ze v tvem postu) not null/unique constraint pak by měli být exekuční plány naprosto stejné. Nezávisle na tom jak jsi to napsal, pokud tam například nemáš ten not null constraint pak jsou to dva uplně jiné příkazy (ačkoliv vzhledem k datum dávají stejný výsledek) a tedy i jiné prováděcí plány a muj odhad (vzhledem k většímu množství informací) by byl že to s tim joinem pak poběží rychleji, jinak imho stejný plán a tedy stejně rychle.

* typicky = sql stroj nemůže při větším počtu tabulek projít všechny kombinace (pro příklad Oracle 10g - 60 000 kombinací, Oracle 11g - jíná strategie 2000 po fragmentech) a tedy pokud to napíšeš jinak při větším počtu tabulek tak budou jinak i exekuční plány, ale to pouze tim že neprohledal celý stavový prostor a tam je pak doslova náhoda, co bude lepší.