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