Vlákno názorů k článku Uložené procedury, event scheduler a informační schémata MySQL od awe_cz - Nemuzu se zbavit dojmu, ze tady exhumujeme mrtvoly....

  • Článek je starý, nové názory již nelze přidávat.
  • 2. 8. 2006 0:51

    awe_cz (neregistrovaný)
    Nemuzu se zbavit dojmu, ze tady exhumujeme mrtvoly. Doufal jsem, ze uz jsou odpornosti typu ulozenych procedur v (T)SQL definitivne mrtve a zjevne ne. Zajimalo by mne, co na nich autor vidi, prosim, argumenty typu "je to rychly" nechte doma.
  • 2. 8. 2006 8:50

    Pavel (neregistrovaný)
    To je otázka? Nechci se Vás nijak dotknout, ale člověk musí pochopit o co jde. Před pár roky jsem měl stejný názor, a myslel jsem si, proč se procedury nedají napsat třeba v basicu. Pak jsem jich pár napsal a změnil jsem názor. Na TSQL a obdobných jazycích je suprová jejich integrace s SQL. Samosebou, že "klasické" funkce se v těchto jazycích píšou dost špatně. Ale od toho jsou v moderních databázích ostatní jazyky. Rozhodně si nemyslím, že T-SQL nebo PL/SQL případně PL/pgSQL jsou mrtvoly. Je to otázka vkusu. Myslím si, že se SP jazyky parádně doplňují s klasickými, což je důvod proč je v Oracle integrovaná java a v SQL Serveru C#. A do MySQL se něco takového chystá. Pro ukázku, v PL napíši iteraci skrz dotaz
    FOR r IN SELECT * FROM tabulka LOOP
      IF r.x IS NOT NULL THEN 
        RAISE NOTICE ..
    END LOOP
    
    V podstatě používám pouze SQL příkazy. Nedochází k žádnému přetypování, používám nativní SQL typy, Totéž v PL/Perlu
    $sth = spi_query("SELECT * from tabulka");
    while (defined ($row = spi_fetchrow($sth)))
    {
       if ($row->{x}) 
       {
           elog(NOTICE, ...
       }
    }
    
    PL/pgSQL mi přijde mnohem názornější. Logiku procesu neutápím v uvozovkách, závárkách, atd. Což je ten hlavní argument, proč se naučit a používat ještě jeden jazyk. Jinak je to diskuze o tom, který jazyk je lepší,Java, c#, pascal nebo PL/SQL, T-SQL. Nebo zda používat spacializované jazyky nebo používat jeden univerzální. Z funkčního hlediska jsou tyto jazyky rovnocené. To, co tu píši platí pro SQL databáze. U objektových databází jsou pravděpodobně vhodnější klasické OOP jazyky. Psát formátovací funkci v PL/pgSQL nebo T-SQL je opruz. A výsledný kód se stejně bude relativně pomalý (mimo novější verze Oraclu, kde PL/SQL má klasický překladač). Tak ji napíši v perlu.
    CREATE OR REPLACE FUNCTION separate_entry_and_code (
       IN entry varchar, 
       OUT code varchar, 
       OUT description varchar) 
    AS $$
            use locale;
            my $code, $description;
            if ($_[0] =~ m/^(<([^>]*)>\s?)?(.+)$/ )
            {
                    $code = $2;
                    $description = "<![cdata[$3]]>";
            }
            return { code => $code, description => $description };
    $$ LANGUAGE plperl;
    
  • 2. 8. 2006 12:06

    awe_cz (neregistrovaný)
    Nemohu souhlasit. Zkuste si napsat kod, ktery prochazi vysledek selectu napriklad v Jave a v T-SQL, je to docela rozdil. Napriklad ze syntaxe cursoru je mi na bliti. Naprosto "nejlepsi" je, ze mate dve moznosti, jak to delat a obe jsou naprosto zrudne:

    while (1=1)
    fetch ...
    if (@@sqlstate <> 0) break
    ...
    end

    nebo pripadne

    fetch ...
    while (@sqlstate <> 0)
    ...
    fetch ...
    end

    A to nepocitam declare cursor, open, close, deallocate, brr. Nebo si potrebujete nekde vypsat nejakou debugovaci informaci, ano jiste, mame print. Jenze - print funguje jenom na stringove typy a konverzi nejde delat primo ve vyrazu, takze vypsani cisla znamena:

    declare @tmp varchar(255)
    select @tmp=convert(varchar(255), @cislo)
    print @tmp

    Tomuhle rikam jazyk, co cloveku usetri praci !
  • 2. 8. 2006 12:46

    Pavel (neregistrovaný)
    To by mne taky štvalo. Tohle vychází z dávno zastaralé ANSI SQL 99. V ANSI SQL 2003 SQL/PSM už je konstrukce FOR, která toto řeší. PL/SQL a PL/pgSQL FOR podporují, T-SQL a MySQL zatím (snad) ne. Tou dobou (v půli devadesátých let) byla móda minimalistických jazyků, a FOR je duplicitní vůči WHILE. Stejným neduhem trpěl i první OBERON. Pracnost výstupu microsofty netrápí, mají debugger, a navíc není problém si napsat procedury, které print zapouzdří. V Postgresu to bylo stejné omezení, než jsem se nas.. a upravil RAISE NOTICE, by byl o něco praktičtější. Ke všemu má starší T-SQL oproti SQL/PSM dost primitivní zachytávání chyb, ale to jsou celí microsofti. V jejich pojetí, byla databáze chytřejším FS. V tom se dost podobali MySQL. Měli dost odlišnou strategii a T-SQL podle toho také vypadalo. Podívejte se třeba na PL/SQL, které je úplně o něčem jiném.
  • 2. 8. 2006 15:49

    tng (neregistrovaný)
    No tak dejme tomu v javascriptu by to mohlo vypadat takto:

    forEachRow("SELECT * from tabulka",
    function (row) {
    if (row["x"])
    elog(NOTICE, ...
    })

    nebo v Lispu:

    (for-each-row "SELECT * from tabulka" (x)
    (when x
    (elog NOTICE ....)))

    ;-)
  • 2. 8. 2006 20:00

    Pavel (neregistrovaný)
    Ne kazdy se chce učit Javascript nebo Lisp :-). Nicméně, cca před měsícem jsem vypisoval témata na dimplomky a jedním je i embbeded javascript běžící podle potřeby dynamicky na serveru nebo klientu. Viděl jsem komerčně úspěšně používat E C++ - příklad dotažené matfyzacké diplomky.
  • 2. 8. 2006 16:11

    tng (neregistrovaný)
    Obecne proste moc nevidim duvod, proc kvuli par syntaktickym neprijemnostem pri embeddovani SQL prejit na specializovany jazyk, ktery je sice 100% integrovany s SQL, ale naprosto neschopny v cemkoliv jinem.