Minule jsme načali látku o pokročilých technikách sestavování SQL dotazů tím, že jsme si ukázali, jak se dá sestavit dotaz na duplicitní položky a dotaz na chybějící záznamy. Dnes budeme v rozboru náročnějších dotazů pokračovat. Ukážeme si, co může vzniknout za problémy, když se rozhodnete vracet pořadová čísla záznamů.

"Očíslované" záznamy

Čas od času je třeba vrátit sadu záznamů, která obsahuje jako součást vracených dat i pořadové číslo záznamu. Může to být potřeba například při sestavování výsledkových listin v nějakém soutěžním klání, jako podklad pro tvorbu kalendářů a podobně. Mějme třeba jako data tabulku:

a chtějme vrátit lidi podle jejich platů (nejbohatší nejvýše) s tím, že seznam bude očíslován. Jak na to? Existuje několik řešení.

Řešení s dočasnou tabulkou

První, co by někoho mohlo napadnout je, že k tabulce by se mohlo přidat automaticky číslované pole, a pak ji prostě vrátit i s tímto polem:

Tento přístup má však mnoho omezení, v praxi většinou takových, že se to nedá použít vůbec:

• Každá tabulka smí mít jen jedno automaticky číslované pole
• Odmazáním záznamů vznikne v číslené řadě "díra", kterou MySQL nezaplňuje
• Toto číslování funguje jen pro celou tabulku, pokud budeme chtít data seřadit nebo vybrat jen některá, je nám tento postup víceméně nanic.

Ačkoli by se zdálo, že se tím nemá cenu déle zabývat, může mít tato technika vracení "očíslovaných záznamů" své zastánce, zejména pokud ji trochu upravíme. MySQL totiž může fungovat takto:

1. Vytvoříme si sadu záznamů, která nás zajímá
2. Tu umístíme do dočasné tabulky
3. K dočasné tabulce přidáme automaticky číslované pole
4. Pak z ní vybereme data a ta vrátíme volající aplikaci

Celé to předveďme na příkladu. Budeme chtít vrátit seznam zaměstnanců s tím, že budou seřazeni podle platu (sestupně) a očíslováni. Řešení?

Toto řešení samozřejmě předpokládá, že v původní tabulce neexistovalo pole id. Pokud by existovalo, je druhý řádek z příkazu výše zbytečný. Tahle metoda je občas cenná, protože na jednu stranu sice přesypává kvanta čísel, na stranu druhou však může i tak být dost rychlá. Druhé řešení, které vám předvedu, totiž trpí poměrně výžnými výkonostními problémy.

Řešení s poddotazem

Tohle řešení nepoužívá dočasnou tabulku, ale poddotaz. A to poddotaz korelační, tedy takový, kde se data z vnitřního dotazu vztahují k dotazu vnějšímu. Nejprve jej předvedu:

a teď vysvětlím - vnořený poddotaz prostě vrátí počet všech zaměstnanců, kteří mají stejný nebo vyšší plat než aktuálně zpracovávaný zaměstnanec. Což znamená, že de facto vrátí počet zaměstnanců majících vyšší plat než zpracovávaný záznam. Jak už to na tom světě bývá, i tohle řešení má háček, a to ten, že když by měli dva pracovníci stejný plat, vrátí jim poddotaz stejné pořadí. Což je logické - v takovém případě totiž existuje "stejný počet kolegů, majících stejný či vyšší plat".

Jak z toho ven? Je tu jeden způsob - a to ten, že si "vypůjčíme" ještě nějaké další pole pro řazení. V našem případě bychom například mohli řadit jednak sestupně podle platu, a jednak jména podle abecedy. To všechno proto, abychom měli zajištěno pevné pořadí i v rámci skupiny se stejným platem. Dotaz, fungující dobře i pro záznamy s více lidmi se stejným platem by pak mohl vypadat takto (důležité pasáže jsem zvýraznil):

Když si poddotaz přečtete a zamyslíte se nad ním, je to opět logické. Vrací totiž:

• Počet lidí majících vyšší plat než aktuální zaměstnanec, plus
• Počet lidí majících sice stejný plat, ale příjmení, které je dříve v abecedě

Pochopitelně, poddotaz by nefungoval správně, kdyby řazení v hlavním dotazu bylo jiné.

Pozn.: Vnímavý čtenář může namítnout, že v reále lze mít dva lidi jak se stejným jménem, tak i se stejným platem. Ono se to ve skutečnosti většinou ještě řadí podle nějakého jedinečného identifikátoru řádku (například, podle automaticky číslovaného pole), takže tento problém nenastává.

Řešení se spojením

Pokud jste se rozhodli přepsat výše uvedený poddotaz na spojení, mám pro vás dobrou zprávu - jde to. Člověk musí pouze dát pozor na to, že v hlavním dotazu je pak nutné použít klauzuli GROUP BY, neb agregační funkce COUNT(*) musí počítat pouze s počty "předcházejících" zaměstnanců pro konkrétního pracovníka. Mohlo by to tedy dopadnout nějak takto:

Závěr

Jak vidíte, vracet jako součást dat i pořadová čísla řádků není až tak úplně jednoduché. Někteří programátoři proto volí jiný přístup - nechají data sestavit bez čísel řádků a ve volající aplikaci pak zpracovávají data po jednotlivých záznamech. Aplikace sama si vytvoří a spravuje jakýsi čítač, s nímž se pak manipuluje. Řešení, které jsem předvedl, však může být mnohem elegantnější, protože udržuje aplikační logiku v databázi a nemá ji roztříštěnu mezi databázi a aplikaci.

Co si vyberete záleží pochopitelně na konkrétní situaci. Pokud budete číslovat větší počet záznamů, udělejte si nějaké testy rychlosti - jednotlivé metody zde uvedené se mohou mít až řádově odlišný čas provádění!