Ušetřete

Hlavní navigace

Názor k článku
Nový pohľad na tradičný relačný model

Inkvizitor
Inkvizitor (neregistrovaný) ---.net.upcbroadband.cz
9. 6. 2011 23:36 Nový

Re: moudra

celé vlákno

Jenže já jsem psal o případu, kdy NELZE používat stále ten samý algoritmus prostě proto, že různých dotazů (s různými vyhledávacími strategiemi) nad daným databázovým schematem může být strašná spousta (jak o tom psal koneckonců třeba Ivan). Pak máte možnost buďto systém z uživatelského hlediska svázat tak, že bude možné zadávat jenom omezenou množinu dotazů (s případnými rozsahy parametrů) nebo se zaměřit na jeden (v ideálním případě) typický případ a holt se smířit s tím, že v méně typických případech bude vyhledávací plán dost nevhodný. Třetí možností je pouze napsat si pro každou aplikaci vlastní plánovač, který ty dotazy skládá - koneckonců natvrdo napsané pořadí vyhodnocování je dá se říci mezní případ plánovače. Je samozřejmě možné kritizovat možnosti plánovače v určitém databázovém produktu, ale je řešením na plánovač úplně rezignovat, když hrozí, že se mu občas nezadaří?

Co se týče možné paralelizace vykonávání sekvenčního kódu (to je sám o sobě trochu protismysl), v některých případech to možné samozřejmě je, ale právě jen v případech, kdy nezáleží na pořadí vyhodnocování. Když napíšu


a := 2 * 2
b := 3 * 3
c := a * b

je to snadné. Jak ale v imperativním jazyce obecně paralelizovat následující kód?


a := proc1()
b := proc2()
c := a * b

Kolik programů je psáno tak, aby ty proměnné byly skutečně nezávislé a nebylo to něco v následujícím stylu?


a := 1
b := 2
while a < 30:
a := a + b
b := a + 1
end

Jakmile se programátor začne vrtat v pořadí vyhodnocení, efektivně tím brání automatické paralelizaci. Pokud zapomene na slovo proměnná (ve smyslu paměťová buňka), dává systému šanci optimalizovat podle momentální potřeby. A to se nebavíme o nelokálních proměnných, které do toho vnášejí ještě daleko větší problém.