SQL a rekurze

jaka je u prvniho prikladu vyhoda oproti klasickemu
"SELECT a,b FROM edges WHERE a != 1;"?

Nenapada me priklad ve kterem bych nemohl podminku vyjadrit WHEREm primo. Mozna jedine u klauzuli typu UPDATE, ktere MySQL neumi vyhodnotit s vnorenym dotazem nad tou samou tabulkou "UPDATE ... WHERE foo = (SELECT ... LIMIT 1)".

[1] To jste se nedostal před první odstavec. Tam je ten příklad skutečně špatný :-)

A tady zjevně nešlo o where podmínku, ale o rekurzi. Jednodušší úloha: máte tabulku "directories", kde je sloupec s názvem adresáře (primární klíč) a názvem nadřazeného adresáře (shodný s názvem adresáře, pokud je to kořen). A pak tabulku "files", kde je název souboru (primární klíč) a název adresáře, kde je soubor uložen. A úloha zní vypsat seznam souborů a ke každému seznam adresářů z cesty k němu. Případně vyšší dívčí - seznam souborů a ke každému textový údaj s celou cestou k souboru. A vypořádat se pak i s chybou, když se adresáře zacyklí (A / B / C / D / B).

[1] where neni mnozinova operace.
Obdobny priklad by byl s tabulkami:
tabulka1 tabulka2
-------- --------
A A
B B
C
D

Vypsat ty, ktere nemaji zaznam v tabulce1.

Hmm, netusil jsem ze se mi po ulozeni komentare ty tabulky rozbiji. Tak tedy Tabulka1{A,B} Tabulka2[A,B,C,D}

[3] Jenže ten příklad byl nad tabulkou jedinou. V tom je špatný. Kdyby to byly tabulky 2, tak to bude jasnější. Ale i pak řada SQL programátorů použije WHERE (a,b) not in (SELECT...)

[1] Ten priklad s WHERE nemusi dat vzdy shodne vysledky. EXCEPT udela jeste DISTINCT, to same plati pro NOT IN zmineny v [5].

Malé povědomí o CTE si vysvětluji tím, že až donedávna existovaly jen v DB2 a ta se v našich končinách moc nevyskytuje. Odkdy je má Oracle? (btw o Postgresql vím)

[7] Oracle to podporuje minimalne od verze 10g (viz query factoring). Tzn 11 let. Jojo leti to leti.

Dakujem za podnetny blog.
Nebolo by lepsie celu tabulku nacitat do pamete a naprogramovat rekurziu v programe? Nie som odbornik, ale zda sa mi ze tento dotaz prejde tebulku hran nie raz, ale viackrat podla poctu hran.

[9] existuju ludia ktori oblubuju programovanie v databazach. Pre takych su taketo hratky.
Z praktickej skusenosti si myslim, ze len s namahou dosiahnete vykonovo lepsi vysledok naprogramovanim to v inom jazyku. (mozno je toto vynimka potvrdzujuca pravidlo)

@9 Ono to tak v praxi často je. Nicméně vyhodnocení prostou rekurzí není většinou možné, proto se používají ty pevné body nebo nějaký ještě obecnější algoritmus, co se nezacyklí.

[9] Pokud by šlo čistě o iteraci, tak program v C nad daty v paměti bude cca 20x rychlejší - a pokud by rekurzivní prohledávání dat byla primární úloha, tak existují vhodnější nástroje než je relační SQL databáze. Nicméně rekurzivní prohledávání dat může být jen jednou z mnoha úloh, které chcete s daty v databázi dělat - např. operacemi nad číselníky získat seznam idček a pak dál už pracujete klasicky relačně - nebo rekurzí získáte popisky, které přijoinujete k agregovaným hodnotám - a pak se může hodit, že SQL databáze rekurzi umí. I když je relační databáze pomalejší než specializovaný sw, pořád umí vracet (i s rekurzí) desítky tisíc řádků za vteřinu, což na hodně úloh bohatě stačí. Určitě nemá relační a nemůže relační databáze s CTE zastoupit specializované grafové databáze nebo algoritmy, které jedou čistě nad maticemi v paměti - primárním účelem relačních databází je management dat - a CTE je aby se některé věci dělali pohodlněji.

Pokud byste chtěl dělat rekurzi nad daty uloženými v databázi externě, tak pak musíte počítat s režií exportu dat mimo databázi - network, interproces communication

[10] Programování v DB má význam například v okamžiku, kdy se vám mezivýsledky nevejdou do paměti a musíte mezivýsledky odkládat na disk. (BTW: Osobně jsem odpůrcem uložených procedur a triggerů jako standardního vývojového nástroje. Aplikační logika do DB dle mého názoru nepatří.)

CTE bez rekurze nemusí být jen syntaktický cukr. Jejich správné použití se může projevit na rychlosti výpočtu. Např:

with COMPLEX_QUERY as ( select ..... )
select ...
from COMPLEX_QUERY as A
join COMPLEX_QUERY as B on ....

Bez CTE většina databází vyhodnotí COMPLEX_QUERY 2x (bohužel).

@TomasJ "Syntaktický cukr" znamená, že to jde zapsat bez CTE. Takže bez rekurze to syntaktický cukr je a implementace je irelevantní (aspoň u deklarativních jazyků, a to SQL je).

[13] BTW: Osobně jsem odpůrcem uložených procedur a triggerů jako standardního vývojového nástroje. Aplikační logika do DB dle mého názoru nepatří.

Takový Oracle Forms+Oracle PL/SQL..., ve Forms jenom logika formuláře, aplikační logika v packages v DB ;-)

Poznam to, riesenie cez Oracle forms bolo ponuknute zakaznikovi ako rozhranie, a ked sa to naucil pouzivat tak tam pridaval vypocty a na vypocitane hodnoty dalsie vypocty a tak asi 5 rokov. Potom bol DB server tak zatazeny ze niekedy jednoducho nieco nevypocital, bohuzial bolo nahodne co. Potom bolo treba zistit kde je diera v datach a dopocitat to.
Ale uvedomujem si ze to je ojedinely pripad, na jednej oracle konferencii sa prednasajuci spytal publika aby zodvihli ruku ludia co je ich server zatazeny nad 20% a zodvihol som ruku len ja.

[15] Triggery jistě, ačkoliv je to bez nich občas hodně velké zesložitění. Nicméně bez procedur si nedovedu představit rozumnou aplikaci, kde programátora zajímá integrita dat. Zvlášť v případě, že do databáze dělají zásahy aplikace od více dodavatelů.

Mimochodem, řeší článek nějakou konkrétní implementaci, nebo jde o obecné SQL? Protože to v něm není uvedeno. Řešit obecné SQL je dle mého názoru víceméně zbytečné (bohužel).

[17] Celý frk spočívá v tom, že vyjadřovací schopnosti vyšších jazyků (a jejich ladicích nástrojů) jsou někde úplně jinde než PL/SQL. Takže ono jde veškerou doménovou logiku nacpat do DB, ale prcačka je to neskutečná. Takže jestliže to jde, můžou cizí aplikace využívat ne rozhraní DB, ale rozhraní vyššího jazyku (když to zvládnou).
Druhým problémem je umístění dom. logiky do persistentní vrstvy, v případě, že ji potřebujete prohodit (např. za dokumentovou DB), můžete to všechno předělat.