Názory k článku Uložené procedury, event scheduler a informační schémata MySQL

Datulka je nádherné slovo, ale myslím, že jako náhrada tabulky se asi neujme :)

kouzlo nechtěného

datulka = datová tabulka, to přece každý pozná! :-))) je to roztomilé.

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.

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;

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 !

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.

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 ....)))

;-)

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.

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.

Z tohoto predpotopniho jazyka je mi na bliti, radsi se podivejte, jak na to jde c# 3.0 :)

Před 40 roky IBM měla také univerzální jazyk, který uměl všechno. Jmenoval se PL/1.