Filtrační panel je v mnoha aplikacích to místo, kde končí možnosti platformy. Podmínky jako „stav je Otevřeno“ nebo „vytvořeno za posledních třicet dní“ zvládne skoro každý nástroj. Jakmile ale potřebujete něco víc – složené podmínky, filtrování přes vazby mezi objekty, parametry, které si uživatel sám doladí, nebo výseky dat, které stojí za to uložit a sdílet –, obvykle se neobejdete bez vývojáře, samostatného reportovacího nástroje nebo tabulky. Tvůrce dotazů tuhle mezeru zaplňuje. Umožní i lidem bez technického zázemí přesně popsat, jaká data chtějí, uložit tento popis jako pojmenovanou položku a používat ho kdekoli.
Dotazy jsou plnohodnotné objekty platformy. Ukládají se, mají jméno, řídí se oprávněními, dají se překládat i sdílet a žijí ve stejném objektovém modelu jako všechno ostatní. To má dva praktické důsledky. Dotaz jednak není uvězněný v jednom pohledu – tentýž dotaz může současně napájet tabulkový pohled, kanban, naplánovaný e-mail, procházení v automatizaci, koncový bod REST API i dlaždici na domovské stránce. A jednak se dotazy dají spravovat centrálně: správce je může kontrolovat, upravovat jim oprávnění, mazat zastaralé a dokumentovat je stejně jako kteroukoli jinou část implementace.
Samotný tvůrce je vizuální. Podmínky pokrývají rovnost, rozsahy, obsahování, začátek textu, regulární výrazy, kontrolu existence hodnoty i filtry, které projdou po vazbách až k vlastnostem souvisejících záznamů. Dotaz nad fakturami tak může na jedné obrazovce filtrovat podle částky > 5000, podle data splatnosti v minulosti i podle customer.country = Německo, aniž by kdokoli psal spojení tabulek. Podmínky se skládají pomocí AND a OR a dají se vnořovat, takže i mírně složitější výsek – „zákazníci z Evropy, kteří mají alespoň jednu fakturu po splatnosti NEBO zůstatek nad určitou hranicí“ – je čitelná struktura, ne odstavec textu.
Právě parametry dělají z dotazu něco víc než statický seznam. Parametr je pojmenovaný vstup, který dotaz nabízí – například region, od kdy nebo řešitel – a má určený typ. Když dotaz použije nějaký pohled, může parametr buď natvrdo nastavit na konkrétní hodnotu, nabídnout ho uživateli jako ovládací prvek, nebo ho nechat skrytý s výchozí hodnotou. Jediný dotaz obchody v regionu tak může obsloužit tři pohledy: jeden pro Severní Ameriku (parametr pevně daný), druhý, kde si uživatel vybere libovolný region (parametr viditelný), a třetí, který se přednastaví na region přihlášeného uživatele, ale dá se změnit (výchozí, ale upravitelný). Tři pohledy, jeden dotaz a jedno místo, které určuje, co v daném kontextu znamená „obchod“.
Stojí za to znát ještě jedno upřesnění: parametry existují ve třech podobách – pevné, výchozí a skryté. Pevný parametr pohled zamkne. Výchozí přichází s počáteční hodnotou, ale zůstává upravitelný. Skrytý je neviditelná výztuž – filtr, který systém potřebuje nést dál, ale uživatelé se ho dotýkat nemají. Tyto tři režimy pokryjí prakticky všechno, co v praxi potřebujete.
Řazení může být podle více sloupců, každý sloupec vlastním směrem, a výchozí řazení dotazu se stane výchozím řazením každého pohledu, který na něm stojí. Na úrovni dotazu se nastavuje i seskupování a výpočty, takže dotaz jednou popsaný jako „seskupeno podle regionu, sečteno podle částky“ je v této podobě dostupný všude – včetně automatizace, která rozesílá týdenní souhrn, i exportu, který skončí v tabulce finančního oddělení.
Náhled dotazu je sice drobnost, ale v praxi opravdu užitečná. Jak dotaz skládáte, živý náhled průběžně ukazuje aktuální výsledky. Ještě než podmínku potvrdíte, vidíte, co udělá; snadno odhalíte filtr, který omylem vyřazuje příliš mnoho záznamů; a ověříte si, že parametr dělá to, co si myslíte. Právě tahle rychlá zpětná vazba umožňuje, aby si funkční dotazy skládali i lidé bez programátorského zázemí, bez čekání na někoho dalšího.
Popisy dotazů celou práci s dotazy zaokrouhlují. Krátký odstavec připojený k dotazu ostatním prozradí, k čemu slouží, co znamenají jeho parametry a jak se má používat. Jakmile se sdílených dotazů nasčítají desítky nebo stovky, jsou to právě popisy, které rozhodují o tom, jestli vznikne užitečná společná knihovna, nebo hřbitov dotazů, u kterých si už nikdo nevzpomene, proč vznikly.
Dotazy navíc nepohánějí jen pohledy. Automatizace procházejí výsledky dotazů – naplánovaná úloha může každou noc proběhnout nad výstupem dotazu a rozeslat souhrn, poslat oznámení ke každému řádku nebo aktualizovat všechny záznamy, které vyhověly. Dotazy mohou řídit i akce nad seznamem uvnitř formulářů a mohou parametrizovat koncové body API. Jakmile na dotaz začnete nahlížet jako na přenositelný kus logiky, a ne jako na vnitřek filtračního panelu, jeho dosah je hned jasnější.
Článek o pokročilém filtrování se podrobněji věnuje vnořeným podmínkám a poddotazům pro případy, kdy jedna plochá sada podmínek nestačí. Článek o uložených dotazech a seznamech filtrů popisuje, jak si uživatelé dotazy předávají mezi sebou i napříč celým prostředím. A článek o pohledech ukazuje, jak se z dotazu stane čočka, přes kterou lidé s daty pracují každý den. Všechny tři na tento text přirozeně navazují; tvůrce dotazů je základ, na kterém všechny tři stojí.