Názory ke článku Výhody databázových procedur – Programujte.com

Zajimave,
diskutujete tedy zda aplikacni logiku ulozit do ulozenych procedur na server nebo ne?
Par software to pouzivalo, ale upustilo se od toho. Jazyk pro programovani stored procedures je prilis omezeny, tedy vsechnu logiku stejne nemuzete mit v SP. Takze je lepsi mit vsechno na aplikacnim serveru, nez to rozdelovat na vice mist.

Diskuze zda je dulezitejsi behova rychlost aplikaci nebo rychlost vyvoje uz je take rozhodnuta ve prospech rychlosti vyvoje.

Reagoval na komentář od uživatele xdrm :

Díky za komentář. Máte pravdu v tom, že stored procedury jsou v porovnání s plnohodnotnými programovacími jazyky omezené. Ale to co umí, umí velmi dobře... a to je právě práce s daty. Na další věci, jak píšete, je tu aplikační server. Nechtěl jsem vzbudit nejmenší dojem, že je správná cesta všechnu "aplikační" logiku přesunout do databáze. Přesunul bych tam pouze tu, která pracuje s daty.

Na druhou stranu nechat úplně všechno pouze na aplikačním serveru není také nejlepší řešení. Myslím si, že důvody jsem naznačil už v článku. Pokud se k tomu někdo uchýlí a používá databázi jako "inteligentní filesystém", je pro něj třeba Oracle nebo SQL Serveru zbytečná investice.

Najít přesnou hranici, co kam přesunout se nikomu asi nepodaří. Na druhou stranu by se vždy mělo vycházet z konrkétní situace a požadavků projektu. Neměla by se předem zahazovat možnost použít databázovou funkcionalitu.

Uvádíte rychlost vývoje, ovšem to je velmi relativní. Dám praktický příklad - auditování. V databázi jsem schopen aktivovat auditování pro vybrané operace, tabulky a učty jediným řádkem skriptu. Vše za mě už naprogramovalo a otestovalo desítky inženýrů v Oracle. Jak dlouho (a hlavně kolik) bude stát implementace auditu na aplikační vrstvě?

Clanek jsem sice jenom lehce proletl, ale mam pocit ze uplne zanedbava jednu dulezitou vec, a to skalovani. Pokud vynecham "molochy" ve stylu Oraclu a jeho active-active clusterovani , tak tim, ze /cast, celou/ BL prenesu na stored proc, si dosti intenzivne zaviram dvere smerem k moznosti skalovani systemu . pokud se dostanu do situace, kdy DB se tane uzkym hrdlem, jsem ve slepe ulicce a mam jen dve moznosti - optimalizace (ma sve meze), hw rozsirovani (ma sve meze, a neni spasitelne). zatimco pri BL nekde jinde (napr. na aplikacnich serverech) mohu celkem elegantne a rychle clusterovat tyto. na BL mam oproti SP dalsi moznosti "setreni" vykonu ve forme cachovani vseliceho a takto databazi dosti zasadne odlehcovat, ale pritom si stale zachovavat skalovatelny a rozumne "posilovatelny" system.

Reagoval na komentář od uživatele Štěpán Vacek :

Napada mne jeste jeden problem, zakaznik ma vetsinou admin prava na DB serveru tudiz ma pristup k zdrojovym kodum SP a muze se v nich vrtat. Coz je casto nezadouci.

Dalsi problem je debugovani SP. Pokud to vubec jde tak spatne.

V soucasne dobe neznam software, ktery by ve vetsi mire vyuzival SP :-(

Reagoval na komentář od uživatele xdrm :

Je to pouze o znalosti danych technik. Protoze pracuji s Oraclem, uvedu priklady prave na teto platforme.

1) Databazovou logiku muzete pomerne snadne skryt ocim administratora provedenim tzv. wrapovani, viditelna je pouze specifikace package a nikoliv body, to je v prelozeno do kodu, citelnem databazovemu enginu.

2) Debugovani stored procedur samozrejme mozne je, umi to i nastroj SQL Developer, ktery je dostupny zdarma.

3) Software, ktery vyuziva stored procedury? Napr. je nasazen na systemech vsech mobilni operatoru v CR nebo ve spouste bank a pojistoven. Tj. stredne velke az velke aplikace.

Reagoval na komentář od uživatele Jen - tak :

Ano, uvazuji prave moznosti "molochu" jako je Oracle. Pri jeho pouziti mam totiz temer vzdy kam sahnout. Pracuje system s velkym objemem dat, pak mohu pridat partitioning a v tabulce mit i nekolik stovek gigabajtu. Pokud je problemem vykon, pak lze pridat clustering v podobe RAC a opet tim zvysim vykon. U skutecne "mission critical" projektu je vyhoda, ze lze nasadit samostatne body package a je to bezodstavkova instalace, protoze navazane objekty neinvaliduji... jste schopen tohoto dosahnout na aplikacnim serveru?

Databaze mi nabizi velmi dobre prostredky pro ladeni konkretnich casti databaze (uloziste, objekty, kod atd.). Oddelenim casti logiky (nerikam vsechno do databaze) muzete ladit jednotlive vrstvy.

Zminujete skalovatelnost formou aplikacnich serveru. Pokud vsak pracujete s daty, ktera nejsou v cache, stejne musite do databaze - a stane-li se objem prenasenych/zpracovavanych dat uzkym hrdlem, budete muset tento problem resit na urovni databaze. Nehlede na to, ze kdyz budete mit "praci s daty" na aplikacnim serveru, tak nez k vam data pro mezivysledky vubec stihnou doputovat, budu mit uz spocitany ve stored procedurach finalni vysledek. (Ne vsechno lze spocitat jednim SQL dotazem.)

V clanku i prispevcich jsem psal, ze vzdy zalezi na konkretnim pripadu. Nerikam, ze stored procedury jsou vhodne na vsechno... ale nemeli bychom je na projektu prehlizet jen proto, ze nemame potrebne know-how nebo si myslime, ze to bude na aplikacnim serveru fungovat efektivneji. Jak rika znamy Oracle guru Tom Kyte: "Nikdy nic nepredpokladam a vzdy se chci presvedcit."

Proto i ja se zeptam, mate pro svoje tvrzeni nejaky konkretni priklad?

Konečne je tu dostatočne fundovane napísaný článok so zaujímavou problematikou z pohľadu väčších podnikových riešení. Pravdou je, že osobne som sa v praxi nestretol s projektom, kde by použitie SP prinieslo nejaký výrazný efekt, no článok sa mi páči a dúfam, že autor bude v tejto problematike publikovať viac. Nech sa darí.

Myslím, že vývojář má mít především rozum. My např. používáme SP dost,
protože natahnout tolik dat po siti jinam jen proto, aby se zpracovala,
by bylo zbytecne. Snad vite napred, zda vase aplikace pojede s ostatnimi
aplikacemi v aplikacnim serveru nebo jestli ho mate jen pro sebe a soucasne
zda s databazi pracujete jen vy nebo jeste spousta dalsich aplikaci a kolik je konekci.

Ja myslim, ze aplikacni logika ma byt na jednom miste - v BL. Ta si zavola
rozhrani, ktere muzete implementovat jak chcete. Pokud je na miste SP, tak
ji zavolate. Pro maly objem dat, ktere maji strukturu (napr. klient, smlouvy,
adresy a vlastnosti smlouvy) je lepsi natahnout data do objektů a tam si je zpracovat.
Pokud se pracuje s velkym objemem dat jednoduse, je lepsi kratke volani.

Podle me (a zkusenosti) je slozite zpracovani na strukture maleho objemu dat
natahnout k sobe, jednoduche zpracovani s velkym objemem dat zpracovat v DB.
Tedy male rychle dotazy do databaze s malym objemem prenosu.

Reagoval na komentář od uživatele xdrm :

Pokud třeba přidání klientů odpavídajících určitým podmínkám (pohlaví, věk, nákup určitého produktu) do marketingové kampaně trvá místo jedné sekundy 10 minut (volání padesáti tisíc insertů a souvisejících triggerů), tak vám zákazník za preferenci rychlosti vývoje moc nepoděkuje.

Reagoval na komentář od uživatele Kuku :

Ja nejak nechapu jaky je rozdil v pouziti Stored Procedur VS SQL dotazy pro velice klasicke operace insert/edit/select

Vzdy potrebuji data dostat na klienta a popr. zmenena/nova data zaslat do DB. Kde jsou ty data navic u klasickeho pristupu?

Jen tak pro zajimavost - cely Atlas.cz jede jen na SP. Potom co jsem mel moznost videt jejich architekuru tak uz si ani nedokazu jinak predstavit rozdeleni vrstev u tohoto velkyho obsahoveho portalu.

Jsem zastánce SP a mám proto spoustu důvodů, ale obava z SQL injection mezi ně nepatří. To se dá pohodlně ošetřit i jinak. Vždy, když si tvořím SQL dotaz na klientovi, nikdy si ho sám neskládám z dílčích stringů, vždy používám parametry. Ve VB.NET to pak vypadá nějak takto:

With New SqlCommand
.CommandText = "SELECT Jmeno,Prijmeni FROM Osoby WHERE ID=@ID"
.Parameters.Add("@ID", Data.SqlDbType.Int).Value = 20
...
...
End With

A nemusím se strachovat, že mi proti databázi půjde nějaká nepravost!

U nás se používají databázové funkce hodně. Nese to sebou trochu jiný problém.

Do firmy jsem nastupoval se znalostmi oraclu zhruba na urovni ze existuje. Na PL/SQL jsem si ale velice rychle zvykl a nakonec jsem delal skoro vsechno co slo v databasi.

Problem ktery u me nastal byl ten ze jsem mel celou databasi po ruce a selectil si kazdou vec kterou sem zrovna potreboval celkem bez premysleni s tim ze "jeden SELECT nic nespasi" i kdyz se nakonec ukazalo ze by to slo jen jednou.

Mam dojem ze programovani v databasi zacatecnika snadno strhne k plytvani zdroji.
Tet to dopada tak ze si oracle bere drtivou cast procesoru.

Myslim si ze pokud si clovek taha data na aplikacni uroven trosku vic premysli zdali to opravdu potrebuje a jak toho brat co nejmin.

Samozrejme v tomto pripade je chyba v programatorovi, tedy ve me.