Zložitý JOIN, alebo subselecty

[Stanislav Hruška]

Je to otázka z takého istého súdka ako predchádzajúca téma.
Po niekoľkých mesiacoch musím prepracovať výpočet spotreby. Pri zhliadnutí prvého SQL textu sa mi zježili vlasy. Po vytvorení grafickej podoby sa mi skrížili oči. Viď príloha.
Jedno aj druhé je v podstate priamo nečitateľné. Treba to študovať. Dá sa to vizuálne zjednodušiť použitím subselect-ov.

Keďže kód sa píše pre ľudí, tak podľa tohto pravidla to mám vykonať refactoring = použiť subselect-y.
Neviem čo je výhodnejšie pre PC. Podľa odporúčaní sa mám na hľadisko čo je výhodnejšie pre PC vykašľať.

Otázka znie: čo je výhodnejšie pre PC?

[Delfin]

Dotaz nechapu. Jednu radu bych tu vsak nechal; zkus se uz naucit analyzovat execution plany a dotazy profilovat. Na otazku na kterou se tady nejspis ptas bys s takovou znalosti odpoved zjistil. Tedy pokud touzis po vykonu pred citelnosti.

[pf1957]

Otázka znie: čo je výhodnejšie pre PC?

Zpravidla se ma za to, ze vetsine optimalizeru na strane RDBMS vyhovuje spis joinovani, nektere umi prevracet join<->subquery podle toho, co jim vychazi lepe. Ale neplati to vzdy. Hodne zalezi, jak a kde se vyskykuji agregacni funkce, jestli ty joiny do vysledku vytahaji duplicity apod.

Takze ja bych se pridrzel tech pravidel:
1. srozumitelnost dotazu a jeho udrzovatelnost, protoze neni vylouceno, ze do toho budes za 1/2 roku muset znovu sahnout
2. co te nepali nehas: vykon bych resil jedine v pripade, ze by se ukazal jako nedostatecny, coz by se projevilo zejmena pri vytvareni nejakeho vyuctovani v davkach a nebylo by unosne si na vysledek pockat.
3. pokud se zpracovava neco v davce, je dobre do aplikace nastrkat mereni casu a vysledky si pamatovat a zobrazovat, abys videl, jak se to v case s narustajicimi daty chova, viz treba graf v mem prispevku http://forum.delphi.cz/index.php/topic,16000.msg98706.html#msg98706
3. No a pokud bys to musel optimalizovat, tak to stejne bude chtit execution plan, z nej navrhnout nejaka opatreni, vytvorit ruzne varianty a ty zmerit a porovnat.

[Stanislav Hruška]

Dotaz nechapu.

Ale pf1957 akoby bol napojený na môj mozog
Obaja ste odpovedali, že na prvom mieste je čitateľnosť a udržiavateľnosť. Momentálne neriešim výkon.

Zpravidla se ma za to, ze vetsine optimalizeru na strane RDBMS vyhovuje spis joinovani,

Mal som na mysli všeobecnú odpoveď tohto typu.
Všeobecne dostávam odpoveď: pozri si execution plan. Čo DB, to iný prístup.

[pf1957]

Všeobecne dostávam odpoveď: pozri si execution plan. Čo DB, to iný prístup.

Ale v obecne rovine je to pravda, jedine execution plan ruznych variant dotazu na konretnim RDBMS poskytne fundovanou odpoved. U Firebirdu necekej od optimalizeru zadne zazraky - je spis minimalisticky.

Obecne to delavam tak, ze uprednostnuju na kazdem RDBMS joiny, pokud to pomoci joinu umim napsat a neleze z toho neco krkolomneho. Ale pokud mi vychazeji subselecty, tak se jim nebranim. A kdyz mam neco hooodne sloziteho, tak opustim funkcionalni zapis, strcim to do SP, ktera mi umozni to proceduralne rozbit na nekolik dotazu v nekolika krocich.

[Daniel_Andrascik]

Rvnako sa prikladam k citelnosti a zrozumitelnosti. A pokial mas databazy s radovo tisickami pripadne desattisicmi zaznamov tak naozaj musel by si nieco velmi pokaslat aby si mal vykonove problemy. Osobne pri nenarocnych databazach s oblubou pouzivam pohlady. Znacne to zvysuje prehladnost a odolnost voci vyvojarskym chybam. A naozaj ked do toho musis po roku a pol znova ripnut tak v mojom pripade som sa v tych pohladoch velmi rychlo zorientoval a urobil dva tri upravy a hura, prec od toho.

[Stanislav Hruška]

Keby FB poznal parametrizované pohľady, tak by som ich používal.

[pf1957]

Keby FB poznal parametrizované pohľady, tak by som ich používal.

Parametry  muzes pouzit akorat v selectu na data, vracena tim view a/nebo vyprasit hafo view pro ruzne hodnoty "parametru"