Pokud dávají smysl oba dva přístupy, udělám dva pohledy. Vy za každý vytvořený pohled platíte, nebo proč je pro vás tak důležité, že je ten pohled jeden a ne dva? Navíc se ty dva pohledy používají v různých situacích, takže se mi to krásně oddělí. Dost možná ty pohledy budou mít i jiné sloupce nebo dokonce připojené jiné další tabulky.
Pokud mám interpretovat určitou vazbu dat, je výhodné mít jeden pohled, třeba i se všemi sloupci, co se nabízejí. V následném selektu pak sloupce omezím jen na ty, které potřebuji. Tím, že v pohledu jsou k dispozici, nic neztratím, ani na výkonu.
Pokud potřebuji mít připojené další tabulky, není nic neobvyklého nad existující pohled postavit další, s dalším joinem.
A proč na to nechci mít dva oddělené pohledy? Inu protože pohledy mají zvyšovat přehlednost - čím méně jich je, tím snáz se revidují. Pokud mi dva pohledy opakují tu stejnou vazbu a jen přidávají podmínku, nedává to moc smysl. Ale kdybych to přeci jen chtěl mít, tak si nejprve udělám pohled interpretující strukturu dat, a teprve nad něj postavím speciální pohledy s filtry. V praxi se setkávám s pohledy s filtry jen v případě, kdy slouží k omezení přístupu k datům (uživatel nedostane práva na samotné tabulky, ale dostane práva jen na zafiltrovaný pohled).
Typicky, mám-li hlavičku dokladu a k ní navázaných 0-nekonečno položek dokladu, pak použiju OUTER JOIN a uložím to jako view. Nad ním pak mohu stavět agregáty (např. count položek). Ze stejného pohledu mi vypadnou jak doklady bez položek, tak doklady s položkami. Po agregaci u bezpoložkových dokladů získám count=0. Nebo použiju agregáty nad parcelami dat. Tento přístup je mnohem výhodnější, než abych v aplikačním kódu zvlášť selektoval doklady s položkami, zvlášť volal agregační funkce, a zvlášť selektoval doklady bez polože.
V případě stromu oprávnění potřebuji od zkoumaného uzlu směrem nahoru vyhodnocovat přístupové oprávnění. Pokud není určeno (OUTER JOIN navrátí v klíči NULL), je to indikátor k tomu přejít k dalšímu nadřazenému uzlu a vyhodnotit dědění práv. Pokud bych měl mít jedno view na existující práva a druhé na neexistující práva, musel bych joinovat tyto dvě views proti sobě. Pokud to mám v jednom provedu JOIN téhož view sama na sebe.
Prostě příkladů, kdy se to hodí je bezpočet a naopak málo případů je, kdy to může být škodlivé.
Na druhou stranu si uvědomuji, že spousta programátorů není schopna napsat select s více než třemi joiny, neumějí joinovat tabulku sama na sebe, zpracovávat parcely dat atd. atd. Právě proto si myslím, že je dobré radit jaké možnosti SQL nabízí a trpělivě vysvětlovat, že SQL optimalizace je vždy úspěšnější, než logiku programovat v aplikaci. Příklad Raccheka je přesně z toho ranku, kdy se dá poradit jednoduché řešení (INNER JOIN), ale i ukázat, že existuje i jiný, a možná zajímavý přístup k věci.
INNER JOIN bych používal zejména tam, kde se neočekává, že odpovídající záznam neexistuje - např. zmíněné číselníky, nebo pravá strana dynamické vazby (tbl1 LEFT JOIN tbl_vazba INNER JOIN tbl_hodnoty - první join nemusí nastat, ale pokud nastane, tak pravý už je obligatorní).
Zobrazit příspěvky
