Hlavní navigace

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

  • 9. 6. 2011 23:36

    Inkvizitor (neregistrovaný) ---.net.upcbroadband.cz

    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.