Databáze > Obecné

Zložitý JOIN, alebo subselecty

(1/2) > >>

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?

pf1957:

--- Citace: Stanislav Hruška  03-02-2018, 11:12:24 ---Otázka znie: čo je výhodnejšie pre PC?

--- Konce citace ---
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:

--- Citace ---Dotaz nechapu.
--- Konce citace ---
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.

--- Citace ---Zpravidla se ma za to, ze vetsine optimalizeru na strane RDBMS vyhovuje spis joinovani,
--- Konce citace ---
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:

--- Citace: Stanislav Hruška  03-02-2018, 20:10:35 ---Všeobecne dostávam odpoveď: pozri si execution plan. Čo DB, to iný prístup.

--- Konce citace ---
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.

Navigace

[0] Seznam témat

[#] Další strana

Přejít na plnou verzi