Nejlepší odpověď
Zatímco spojení i poddotazy mají své místo v příkazech SQL, já osobně se vždy snažím psát své dotazy výhradně pomocí spojení . Mezitím představím pouze poddotaz, když bez něj nemohu načíst data, která chci.
Důvodem je, že spojení mají tendenci provádět rychleji. Ve skutečnosti bych zašel tak daleko, že bych řekl, že doba načítání dotazu pomocí spojení bude téměř vždy rychlejší než u poddotazu.
Důvodem je, že spojení zmírňuje výpočetní zátěž na nahrazením více dotazů jedním dotazem na spojení. To zase lépe využívá schopnosti databáze prohledávat, filtrovat a třídit záznamy.
Samozřejmě, jak přidáváte další spojení k dotazu, musí databázový server dělat více práce, což překládá zpomalit časy načítání dat.
I když jsou spojení nutná k načtení dat z normalizované databáze, je důležité, aby byla spojení napsána správně, protože nesprávná spojení mohou mít za následek vážné zhoršení výkonu a nepřesné výsledky dotazů.
V některých případech mohou poddotazy nahradit složitá spojení a odbory pouze s minimálním negativním účinkem na výkon.
Příklady poddotazů
Někdy se pomocí poddotazu nemůžete opravdu obejít. Zde je několik příkladů použití ukázkové databáze Sakila pro MySQL a mého Navicat vývoje a administrátorského klienta.
Příklad č. 1: Použití agregační funkce jako součásti klauzule JOIN
Většinou jsou tabulky spojeny na společném poli. Ve skutečnosti není neobvyklé, že společné pole sdílí také stejný název, aby se ukázalo, že jde o stejná data. V následujícím dotazu je však tabulka zákazníků připojena k nejnovějšímu (MAX) create\_date, takže výsledky dotazu jsou pro zákazníka, který se zaregistroval naposledy.
Je použit poddotaz, protože nemůžete použít agregační funkce jako součást klauzule WHERE. Toto důmyslné řešení obchází toto omezení!
Příklad č. 2:
V tomto dotazu se používá poddotaz k načtení mezilehlé sady výsledků, abychom mohli použít funkci AVG () na POČET pronajatých filmů. To je to, čemu říkám dvojitá agregace, protože aplikujeme agregaci (AVG) na výsledek jiného (COUNT).
Tento konkrétní dotaz je poměrně rychlý – trvá jen 0,044 sekundy – protože vnitřní dotaz se vrací jediná hodnota. Nejpomalejší dotazy jsou obvykle ty, které vyžadují úplné prohledání tabulky.
Doufám, že na vaši otázku odpovíme.
S pozdravem!
Adam
Odpověď
Obvykle byste měli psát dotazy tak, aby byly co nejjasnější, a ponechat optimalizaci na procesoru dotazů RDBMS a DBA, pokud máte, který je zodpovědný za vyladění fyzického designu. by mělo ve většině případů vést k dostatečně dobrému výkonu, ale existují výjimky. Někdy má optimalizátor dotazů RDBMS slepá místa nebo špatné případy.
Nyní, pokud bude problémem buď spojení nebo poddotaz, optimalizátor, je mnohem pravděpodobnější, že bude v poddotazech. Je to proto, že join je základní vlastnost jazyka, který používají všichni uživatelé, zatímco mnoho uživatelů vůbec nepoužívá poddotazy. Našel jsem v tom převod aplikace ze Sybase na SQL Server jsem musel přepsat mnoho poddotazů jako spojení kvůli chybám v Microsoftu zpracování poddotazů – i když ve velmi konkrétním případě (kde poddotaz, kde klauzule obsahovala vázaný parametr). Není divu, že SQL Server měl chyby v poddotazech, protože tolik jeho zákazníků používá SQL Server s grafickými editory dotazů společnosti Microsoft, které přirozeně vytvářejí spojení, ale ne poddotazy.
Obvykle nedoporučuji předčasnou optimalizaci, ale udělám zde výjimku. Pokud musí být vaše aplikace přenosná na více databázových platformách, preferuji ve většině případů připojení k poddotazům, protože u poddotazů je větší pravděpodobnost, že narazíte na chyby nebo špatné možnosti optimalizátoru. aplikace nemusí být přenosná, napište dotaz tak, jak to vypadá nejpřirozeněji, a pokud nenastane problém – který bude většinou – v pořádku. Pokud nastane problém, přepište dotaz jinak, abyste zjistili, zda to pomůže. A pokud máte DBA, konzultujte s ním jakékoli problémy s výkonem, které máte.