Tím, jak jsme se postupně seznámili s jednotlivými příkazy jazyka SQL pro výběrové dotazy, otevřel se před námi svět databázových dat dokořán. Většina pojednání o SQL, která se mi dostala do rukou v tomto bodě popis příkazu SELECT končí. To je škoda, protože sice jsme si ukázali na mnoho věcí z teorie, stále nám však chybí potřebná praxe.

Při dotazování pomocí SQL se běžně setkáváme s úlohami, které nejsou na první pohled zase až tak jednoduché. Jak byste například provedli dotaz, který vrátí chybějící data v jedné tabulce ve srovnání s jinou tabulkou? Co dotaz na duplicitní položky? Umíte napsat dotaz, který vrátí nejvyšší hodnoty v několika různých kategoriích? Co dotaz vracející jako součást sady záznamů číslování řádků, nebo takový, co umí vracet průběžné součty? Dost mi vadí, že nemám takové náročnější příklady hned po ruce, když je potřebuji. Pokusím se to napravit; v seriálu teď několik takových věcí popíšu. Máte se na co těšit - pokud vím, nebyly tyto informace na českých webech v podobné formě a rozsahu dosud uveřejněny.

Chybějící data

S tímto dotazem jsme se již setkali a je poměrně běžný. Zadání je jednoduché - máme dvě tabulky, které obsahují minimálně jeden shodný sloupec (typicky jsou to tabulky v relaci 1:N) a cílem je zjistit, které údaje z první tabulky se vůbec neobjevují v tabulce druhé. Mějme třeba knihovnu a dvě tabulky - čtenáře a výpůjčky. Cílem bude zjistit, kdo ze čtenářů v knihovně ještě nikdy nic nepůjčil. Tabulka čtenářů by mohla být:

a výpůjčky by mohly vypadat takto:

Jak vidíte, kluci vůbec nečtou. Jak sestavit dotaz, který by to odhalil?

Řešení se spojením

Jedno dobré řešení je spojit obě tabulky levým spojením a výsledný dotaz filtrovat podle vypujcky.ctenar. Jestliže tam bude hodnota null, jde o čtenáře, který si nikdy nic nepůjčil - a toho právě hledáme.

Toto řešení bude vracet výsledky velmi rychle a tudíž se používá velmi často.

Řešení s poddotazem

Existuje však další možnost, a to poddotaz. Odpovídalo by to českému "vyber všechny čtenáře, kteří nejsou obsaženi v tabulce výpůjček". Zapsáno v SQL by to bylo takto:

Kromě toho, že se takto zapsaný dotaz dobře čte, má vlastně jen samé nevýhody. Předně - nebude ve většině případů dost rychlý, a to zejména tehdy, když se budou obě tabulky zvětšovat. Málo zřejmý je ale druhý, mnohem závažnější problém. Pokud by totiž v tabulce výpůjček existoval byť jen jeden záznam s hodnotou NULL ve sloupci ctenar, celé to přestane fungovat úplně. Důvodem je skutečnost, že nelze porovat dvě hodnoty NULL ani hodnotu NULL s jinou známou hodnotou (výsledkem je vždy hodnota NULL). Problém namodelujete takto:

Není to tak hrozné - situace má východisko. Pokud byste na řešení s poddotazem trvali, musíte v něm omezit výběr na ty řádky, kde je zadán nějaký čtenář v tabulce výpůjček, takto:

Jelikož řešení se spojením podobnými neduhy netrpí, doporučuji používat ten první přístup.

Pozn.: Příklad byl zjednodušen. V reálné aplikaci bychom pravděpodobně v tabulce výpůjček měli ještě další pole, a čtenáři by zřejmě byli identifikováni čislem, ne křestním jménem. Na principu to však nic nemění.

Duplicitní položky

Na stejných datech můžeme demonstrovat i další obvyklou úlohu - a to výběr položek, které se v dané tabulce vyskytují vícekrát než jednou. Mohli bychom chtít třeba vědět, kdo má více než jednu výpůjčku. Naštěstí i tady je řešení celkem prosté. Spočívá v použití klauzule HAVING poté, co tabulku výpůjček seskupíme podle sloupce čtenář, nějak takto:

Není v tom žádná magie. Tabulku jsme seskupili podle pole "čtenář" a zajímají nás jen ti, kteří byli v knihovně dvakrát (nebo častěji). Dotaz však není tak podrobný, jak by mohl být. Může se stát, že nás zajímají nejen čtenáři, kteří byli v knihovně častěji než jednou, ale i ostatní data (neboli, v našem případě kdy konkrétně byli v knihovně). Tady musíte být opatrní, protože snadno lze podlehnout léčce a myslet si, že rozšíření prvního dotazu ve smyslu:

zařídí to, co potřebujeme. Kdepak! Tento dotaz vrátí stejný počet záznamů jako dotaz předchozí s tím, že bude uvedeno vždy jen jedno datum výpůjčky. Čili, musíme na to jinak.

Pozn.: Abych byl upřímný, zazlívám MySQL, že dotaz výše jde vůbec provést. V některých DBMS skončí podobný pokus chybovým hlášením ve smyslu tom, že sloupec vypujcky.datum nelze do výsledné sady záznamů zahrnout, neb není v klauzuli GROUP BY. Obecně byste se měli hvězdičkové konvenci vyhýbat vždy, když pracujete se seskupováním záznamů.

Řešením je použít ten první dotaz jako poddotaz, nějak takto:

Tento kód bude fungovat ve všech DBMS a je syntakticky čistý. V rozporu s tím, co tvrdí někteří vývojáři lze tento poddotaz přepsat poměrně jednoduše na spojení:

Je ale pravda, že specielně v tomto případě nebude rychlostní užitek ze spojení tak výrazný. Důvod je prostý - poddotazem nebyla skutečná tabulka, ale výsledek výpočtu. Tabulka pravidelni_ctenari tedy v databázi neexistuje a MySQL ji musí v obou případech dopočítat.