Názory ke článku Výhody databázových procedur – Programujte.com
 x   TIP: Přetáhni ikonu na hlavní panel pro připnutí webu
Reklama
Reklama

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

 

Názory ke článku Výhody databázových procedur

xdrm   NOVÝ
25. 3. 2008

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.

stepan   NOVÝ
25. 3. 2008

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ě?

Jen - tak   NOVÝ
26. 3. 2008

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.

xdrm   NOVÝ
26. 3. 2008

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

stepan   NOVÝ
26. 3. 2008

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.

stepan   NOVÝ
26. 3. 2008

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?

pa3k   NOVÝ
30. 3. 2008

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

silh   NOVÝ
30. 3. 2008

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.

Kuku   NOVÝ
3. 4. 2008

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.

Karel   NOVÝ
13. 4. 2008

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?

Pavel   NOVÝ
30. 4. 2008

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.

Tomáš Berný   NOVÝ
18. 5. 2008

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!

Zdenek   NOVÝ
23. 3. 2009

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.

Přidej svůj názor

×Vložení zdrojáku

×Vložení obrázku

Vložit URL obrázku Vybrat obrázek na disku
Vlož URL adresu obrázku:
Klikni a vyber obrázek z počítače:
 
Podporujeme Gravatara.
Zadej URL adresu Avatara (40 x 40 px) nebo e-mailovou adresu pro použití Gravatara.
Email nikam neukládáme, po získání Gravatara je zahozen.
-
Reaguješ na příspěvek:
Pravidla pro psaní příspěvků, používej diakritiku. ENTER pro nový odstavec, SHIFT + ENTER pro nový řádek.
Sledovat nové názory e-mailem (pouze pro přihlášené)
Sleduj názory ke článku a v případě přidání nového příspěvku o tom budeš vědět mezi prvními.



Hostujeme u Českého hostingu       ISSN 1801-1586       ⇡ Nahoru Webtea.cz logo © 20032016 Programujte.com
Zasadilo a pěstuje Webtea.cz, šéfredaktor Lukáš Churý