Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Granica izmedju baze i aplikacije

[es] :: Baze podataka :: Granica izmedju baze i aplikacije

[ Pregleda: 4584 | Odgovora: 15 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

darko_sudarov
ProConto Software doo
Kikinda

Član broj: 89262
Poruke: 136
*.home.otenet.gr.



Profil

icon Granica izmedju baze i aplikacije17.06.2008. u 09:09 - pre 192 meseci
Tokom jednog razgovora zametnula se tema gde je granica izmedju baze i aplikacije ,ukoliko je uopste i ima..
Naime,dali recimo matematiku cuvati u bazi ili u aplikaciji ,tj sta treba ili bi trebalo da stoji u bazi a sta u aplikaciji...

Posto sam ja veliki ljubitelj baza moje stanoviste je da matematiku koji treba da obavi neka aplikacija (ovde mislim na opste uslove racunanja i prostu matematiku) treba drzati u bazi.

Razlozi su sledaci

1-brzuna
2-programer koji nije toliko upucen u aplikaciju moze brzo i lako da sagleda matematiku
3-lakoca pregleda podataka tj. sve je na jednom mestu ne mora se gledati kod u programu pa uporedjivati rezultat u bazi
4-sloboda za doradu procedura ili trigera tj nacina racuna bez menjanja exe falja
5-menja se baza ,veca mogucnost prilagodjavanja konkretnim potrebama korisnika
6-pouzdaniji rad na daljinu
7-kao sto rekoh ja volim baze :-)


Iz ovog proizilazi da je aplikacija samo interfejs koji salje podatke bazi...Sto naravno nije tacno :-)

Naravno da je moguce napraviti fukcije koje ce racunati sve i svasta u programu ali po meni to treba da radi baza sem u slucajevima komplikovane matematike.

E sada dolazi na red varijantnost,tj mogucnost aplikacije da obuhvati sirok spektar razlicitih oblasti...
Recimo deklarativno obracunski programi(zito,mleko,duvan.....) dali to treba da bude jedan program ili svaki za sebe?

Moje misljenje je da treba da bude svaki za sebe,(sirinom se gubi dubina i detaljnoist programa i izvestaja)komplikuje se zivot svima u projektu ako bi se strpalo u jedan program....

Ovo je moje vidjenje i napominjem da sam pristrasan sto se tice baze pa bi voleo da cujem vasa misljenja o ovoj temi








 
Odgovor na temu

savkic
Igor Savkić

Član broj: 92186
Poruke: 2739



+92 Profil

icon Re: Granica izmedju baze i aplikacije17.06.2008. u 19:19 - pre 192 meseci
> Tokom jednog razgovora zametnula se tema gde je granica izmedju baze i aplikacije ,ukoliko je uopste i ima..
> Naime,dali recimo matematiku cuvati u bazi ili u aplikaciji ,tj sta treba ili bi trebalo da stoji u bazi a sta u aplikaciji...

> Posto sam ja veliki ljubitelj baza moje stanoviste je da matematiku koji treba da obavi neka aplikacija (ovde mislim na opste
> uslove racunanja i prostu matematiku) treba drzati u bazi.

Najpre komentar nevezano za pitanje, deluje mi da je tema takva da bi se diskusija bolje razvila u forumu Baze podataka, pa ako chacka ovo prati mogao bi da prebaci tamo.

Po mom mišljenju sve to zavisi od organizacije, potreba, da li imaš client/server, three tier, multitier... Pravila koja se tiču održavanja samog integriteta podataka treba da budu smeštena u bazi, poslovna pravila mogu ići u bazu ili application server i jedan i drugi pristup imaju prednosti i mane. Primera radi, ako će sa bazom istovremeno raditi više nezavisnih aplikacija bez application servera onda ima smisla staviti sve u bazi, ako pak postoji potreba da se aplikacija veže sa različitim RDBMS (FB, Postgree, MSSQL, Oracle, DB2) onda bi poslovna pravila bolje "legla" u application serveru nego u bazi.


 
Odgovor na temu

DrS
Boris Bjelošević
project manager
Beograd

Član broj: 10226
Poruke: 80
*.dynamic.sbb.rs.

Sajt: www.bjelosevic.com


Profil

icon Re: Granica izmedju baze i aplikacije17.06.2008. u 23:05 - pre 192 meseci
Citat:
darko_sudarov: Iz ovog proizilazi da je aplikacija samo interfejs koji salje podatke bazi...


Ovo je siže tvoje dileme (ako je uopšte i imaš, s obzirom na misli i jačinu razloga koje iznosiš). Ako bazu posmatraš samo kao nešto što čuva podatke, sedi i smrdi, onda je granica jasna. No, savremene baze (na koje pretpostavljam da misliš prilikom postavljanja pitanja) sadrže dooobar deo middle layer(s)-a u sebi, pa je stvarno teško povući tu granicu.

Generalno, i ja sam za varijantu da što je moguće više "matematike" bude u bazi podataka, ali k'o što rekoše pametni pre mene - zavisi od namene i potreba.
possibly the biggest joker among his local crowd and perhaps a future book author on that subject
 
Odgovor na temu

kefalo
Banjaluka, RS, BiH

Član broj: 18959
Poruke: 263
193.170.53.*

ICQ: 178873696
Sajt: home.blic.net/mozlas


+6 Profil

icon Re: Granica izmedju baze i aplikacije18.06.2008. u 10:04 - pre 192 meseci
sta podrazumjevate pod "matematika"?
 
Odgovor na temu

darko_sudarov
ProConto Software doo
Kikinda

Član broj: 89262
Poruke: 136
212.200.34.*



Profil

icon Re: Granica izmedju baze i aplikacije23.06.2008. u 07:29 - pre 191 meseci
Ono sto je savkic nazvao poslovnim pravilima - procesima koji dovode do stvaranja krajnjeg rezultata relevantnog za korisnika ili programera.

Banalan primer bi bio: kolicina * cena
Malo komplikovaniji bi bio: prometom 10 jedinica necega sa svojstvom a,b,c,d dobija se cena g

g = 10 + 0.32(a+0.1-2.12b-c+a*d)

ako je ulov da je a > 0.2

ako je uslov da je a<0.2 po drugim poslovnim pravilim itd,itd....
 
Odgovor na temu

dragancesu
subotica

Član broj: 38340
Poruke: 2189
*.eunet.yu.



+73 Profil

icon Re: Granica izmedju baze i aplikacije23.06.2008. u 10:05 - pre 191 meseci
Sad je malo jasnije.

Podelimo matematiku na dva dela, sistemsku i korisnicku. Ovo sitemska bi bilo recimo obracun poreza, sada je 18% i nema naznaka da ce se uskoro menjati.

Ali ovo u primeru je verovatno zahtev korisnika koji ce se menjati sa promenama na trzistu i trebalo bi da bude u aplikaciji.

Pomozite Micro$oftu u borbi protiv piraterije, poklonite prijatelju Linux
 
Odgovor na temu

darko_sudarov
ProConto Software doo
Kikinda

Član broj: 89262
Poruke: 136
212.200.34.*



Profil

icon Re: Granica izmedju baze i aplikacije23.06.2008. u 11:11 - pre 191 meseci
Zasto tako mislis?

Recimo ako je zahtev korisnika ja mislim da je to bas dobar razlog da se nadje u bazi-zato sto program zadrzava univerzalnost a baza se prilagodjava zahtevima korisnika.

 
Odgovor na temu

Au197/79
Zlatan Kadragić
Minhen

Član broj: 3556
Poruke: 772
195.252.110.*

Sajt: aurelije.blogspot.com


+47 Profil

icon Re: Granica izmedju baze i aplikacije23.06.2008. u 13:33 - pre 191 meseci
Ponekad ova pravila stavljaju u rule engine (mašinte za rezonovanje, ekspertne sisteme). Čitao sam knjigu o Jess-u (java expert system shell) i upravo je skladištenje poslovne logike bila jedna od nabrojanih primena. Pravila se obično zapisuju u nekom lispolikom jeziku, u RuleML XML-u itd, a kod aplikacije i baza ostaju bez promena.



Bolje džaba ležat nego džaba radit.
 
Odgovor na temu

chachka
Srđan Mijatov
Programer
BUS Computers
Kikinda

Član broj: 53780
Poruke: 576
*.ADSL.neobee.net.

Sajt: www.baze-podataka.net


+4 Profil

icon Re: Granica izmedju baze i aplikacije27.06.2008. u 02:07 - pre 191 meseci
Darko je postavio dva zanimljiva pitanja/teme. Nažalost (barem je to moje mišljenje) ova pitanja su proizvela mlaku reakciju. (Verovatno je to znak da su pitanja upravo zanimljiva samo meni :) )



Jedna od osnovnih ideja nastanka baza podataka je centralizacija podataka i njihova dostupnost raznim aplikacijama putem standardizovanog interfejsa. Drugim rečima - ideal je da istoj tabeli s podacima o radnicima pristupa i aplikacija za kadrovsku evidenciju i recimo aplikacija za evidenciju sitnog inventara u upotrebi.
Tako ću i ja poći od predpostavke da jednoj bazi podataka može da prisuta više aplikacija.

Uzeću za primer ono što može jako da zaboli, a to je obračun PDV-a.

Za izračunavanje PDV-a nam je dovoljno da znamo poresku osnovicu i stopu poreza (naravno i forumulu :) ). Ovo navodi na zaključak da je u bazi dovoljno čuvati samo ova dva podataka: poresku osnovicu i stopu poreza, dok se sve ostalo može izračunati.

Ovde u igru ulazi moja predpostavka da ove podatke koristi više programa, pa se tako iz jednog programa štamaju fakture, dok se iz drugog programa vrši mesečni obračun PDV-a i štampanje evidencije. Naravno da stvar bude komplikovanija ova dva programa su radili različiti programeri na različitim platformama. I pored sve sposobnosti ova dva programera, lako se može desiti da zbir obračunatog PDV-a po fakturama neodgovara PDV evidenciji koju prikazuje drugi program. Ključna stvar u nastanku ovakvog problema može biti zaokruživanje! Jedan programer je primenuo zaokruživanje po matematičkim pravilima dok je drugi programer zaboravio da izvrši zaokruživanje već je prikaz na 2 decimale rešio postavljanjem maske za štampanje.

(Digresija: Problem može da nastane i u bazi. Recimo da se radi o InterBase-u 6.0 i recimo da imamo kolonu čiji je tip podataka NUMERIC(10,2). Naravno ovo 2 bi trebalo da označava da ova kolona nemože da pohrani više od dve decimale... ali to nije slučaj sa IB6! On će bez problema u takvu kolonu upisati i podatak sa 3 decimale i kasnije ga takvog i prikazati!)

Da se vratim na temu... Da bi se izbegao problem neslaganja podataka iz dva programa iz priče, programeri su se dogovorili da prvi program izračuna PDV, pravilno ga zaokruži i da ga onda upiše u bazu. Drugi program prilikom obračuna u bazi ima dostupnu i osnovicu i stopu i PDV - milina, reklo bi se.

Ali... posao si širi - postoji potreba za remote fakturisanjem i pojavljuje se treći programer koji je na trećoj platformi napravio program za fakturisanje koji se od prvog razlikuje po tome što nije toliko kitnjast i lak za upotrebu, ali nije zahtevan po pitanju bandwidth-a i može se koristiti remote i sa najgorih modema! Pošto se i ovde u suštini radi o programu za fakturisanje i ovde je programer u obavezi da sračuna PDV, i da ga upiše u bazu pored osnovice i stope.

Ovde može doći do razlike u zaokruživanju zbog korišćenja različite platforme! Ako mi neverujete, setite se baga u originalnom Pentiumu pri računanju sa pokretnim zarezom, ili najnovijeg baga u programu Excel 2007! Nema garancije da dve platforme na isti način rade zaokruživanje. (Ne kažem da nebi trebalo da se računa na isti način, već samo da nebih smeo da se kladim da je to tačno.)

I recimo da do toga i dođe! I sada imamo apsurdnu situaciju da je prvi program u bazi prosledio:
Code:
INSERT INTO fakture (osnovica, stopa, pdv) VALUES (113, 18, 20.42)
dok je drugi program (odnosno treći) bazi prosledio:
Code:
INSERT INTO fakture (osnovica, stopa, pdv) VALUES (113, 18, 20.43)
Za istu osnovicu i za istu stopu su ova dva programa prosledila različite poreze!

Eto nam za čas posla anomalije u podacima. Problem smo napravili još prilikom uvođenja kolone sa izračunatim pdvom!

I šta nam ostaje kao izlaz iz ovog problema? Da matematiku obračuna poreza centralizujemo na jedno mesto! Neko će reći - application server koji se obraća bazi dok se ostali programi obraćaju njemu. Ali ovo se kosi sa osnovnom predpostavkom o upotrebljivosti baze, a to je da baza treba da bude dostupna SVIM programima (i to neposredno)!

Preostaje nam da matematiku obračuna pdva na neki način smestimo u bazu, bilo to procedurama, trigerima ili pogledima.

Naravno bilo bi lepo da neka buduća varijanta SQL standarda definiše i standardizovani "application server" koji bi bio neodvojivi deo samog database servera. (Kako bi to trebalo da izgleda? Nemam pojma - samo me je tok misli naveo na ovakav standardizovani application server.)

Iz gore iznetog sledi da i moj glas ide da se matematika smešta u bazu - što je nekada nemoguće uzimajući u obzir sadašnji tehnološki stadijumu baza podataka.



Drugi deo Darkovog pitanja se odnosio na "varijantnost" (prilagodljivost) aplikacije, odnosno baze. Darko je izneo mišljenje da svaki problem, ma koliko bio sličan nekom drugom problemu, zahteva posebnu aplikaciju/bazu. (@Darko Sudarov - Ispravi me ako sam pogrešio u interpretaciji.)

Ovde se delom slažem sa iznetim stavom. Zašto delom? Moraću da se vratim gotovo 40 godina u prošlost da bih izneo svoje viđenje.

Dakle... vraćam se u kraj šezdesetih i početak sedamdesetih godina, u godine kada je nastala ta divna tvorevina zvana relaciona teorija. Znamo da je otac te teorije slavni E.F. Codd, a posebno ću se osvrnuti na jedan od njegovih radova iz tog perioda "A Relational Model of Data for Large Shared Data Banks" što bi se po naški reklo "Relacioni model podataka za velike deljene baze podataka".

Kakvo je bilo hardversko-softversko okruženje u tom momenu. Kompjuteri su bili veliki i skupi, a programi malobrojni. Ovo znači da nije svako mogao sebi da priušti kompjuter. Posedovanjem kompjuta su se ponosile državne ustanove, banke, velike firme. Izdaci za hardver su bili ogromni i onaj ko je bio u stanju da ih plati, taj je hteo i da opravda investiciju i hteo nehteo morao je da ima programera u svom okruženju, jer bi bez programera tako skupa mašina bila neupotrebljiva.

Podaci su se gomilali, njihova obrada je bila sve komplikovanija, i traženo je rešenje problema organizovanja velike količine podataka.

Ovde ću potegnuti spomenuto Codd-ovo delo, odnosno samo jednu reč iz njegovog naslova, a ta reč je VELIKO!

Relacioni model je nastao kao rešenje za struktuiranje VELIKE količine podataka - ovde se neradi o personalnom imeniku sa brojevima telefona prijatelja i rodbine! Ovde se radi o VELIKOJ količini podataka.

I svaka institucija koja je posedovala taj skupi kompjuter je u isto vreme posedovala i database programera koji je isključivo za njihove potrebe primenjivao najnovija dostignuća u rešavanju struktuiranja podataka. Svaki od tih database programera je pravio bazu podataka i aplikacije isključivo za matičnu firmu i isključivo po zahtevima i potrebama matične firme. I naravno takva baza i takva aplikacija nisu bili primenljivi na bilo koju drugu organizaciju, jer je kako to već znamo svaka organizacija priča za sebe.

Jeste taj programer unutar firme koštao i jeste bio neupotrebljiv van firme, ali je ipak on i dalje koštao manje od tog skupog kompjuterea!

Naravno da ovo gore idealizujem i da u stvarnosti nije baš bilo ovako, ali se nadam da sam dočarao generalnu sliku ambijenta.

Ono što sam hteo da kažem je da je relaciona teorija napravljena u vremenu kada je svaka baza podataka bila namenski i ciljano pravljena za isključivo jednu organizaciju.

Naravno, jedan firma poput Forda se bavila proizvodnjom automobila ali se nije bavila proizvodnjom biciklova koliko god to delovalo slično ili ne. Programeri u Fordu su pravili bazu i programe za praćenje proizvodnje automobila i to isključivo po Fordovoj specifikaciji i nije ih bilo briga da li je taj program primenljiv u Mercedesu, a kamoli da li je taj program upotrebljiv u proizvodnji biciklova! Oni su radili za Ford i tu je prestajala njihova briga o prilagodljivosti programa.

Vremenom su kompjuteri ulazili u sve više organizacija i firmi i postajali sve jeftiniji, a samim tim je i cena rad programera počela značajno da utiče na troškove firme. Nije više bilo isplativo držati veliki tim programera u okviru firme, te su počele da nastaju i softverske firme koje su nudile svoje usluge.

E takvoj jednoj softverskoj firmi je bina priča o prilagodljivosti njenog programa! Program mora da bude extra fleksibilan da bi softverska firma od njegove eksploatacije imala što veću korist. Naravno ovo je sve više počelo da se kosi sa idejom o relacionoj teoriji jer je ona nastala iz potrebe da se struktuiraju VELIKE količine podataka, a počela je da se primenjuje u sve manjim i manjim projektima, što je neumitno dovelo do njene degradacije i stavljanja u podređeni položaj.

Kao što je Savkić rekao - softverskim kućama je bitno da se njihova baza i aplikacija vrte na raznim database platformama. To znači da takav jedan program nesme da iskorištava pogodnosti koje na primer nudi Oracle u odnosu na recimo PostgreSQL, kao što je na primer upotreba analitičkih funkcija u SELECT naredbama!

To je isto kao da auto Formule 1 vozite kroz grad koji je načičkan semaforima. Bez obzira koliko je taj auto brz, praktična brzina kretanja je 60 km na sat uz naravno povremene bljeskove u ubrzanju, zvuku i zadivljenim pogledima koje ostavljate za sobom.

Softver se jednostavno sve manje i manje pravi namenski, a sve više i više se pravi tako da zadovoljava što veći krug klijenata. To praktično znači da će isti softver za obračun sa kooperantima koristiti i u mlečnoj i u duvanskoj industriji uz nekakvu parametrizaciju unutrašnjeg ponašanja softvera.

Da li je ovo dobro? Mislim da nije, i mislim da je zaista svaki problem priča za sebe, i da kao takav zahteva specifični pristup i specifično rešenje. Nažalost, uslovi na tržištu su takvi da je ovakav stav osuđen ili na propast ili na korekciju i popuštanje.

Kao primer gore iznetog, navešću banalan problem strukturre konta glavne knjige u dve imaginarne firme.

U jednoj firmi se koriste konta dužine 6 cifara, dok se u drugoj firmi koriste konta dužine 8 cifara. Prvoj firmi bi prirodno odgovaralo da je konto definisan kao tip podataka CHAR(6) uz dodatni CHECK CONSTRAINT koji će proveriti da se konto isključivo sastoji od cifara i da je tačno dužine 6. Drugoj firmi prirodno odgovara da je konto definisan kao tip podataka CHAR(8) uz dodatni CHECK CONSTRAINT koji će proveriti da se konto isključivo sastoji od cifara i da je tačno dužine 8!

Da se radi o gore spomenutom Fordovom programeru, bilo bi mu nametnuto da koristi recimo 6 cifara i da ga baš briga što Mercedes koristi 10 cifara! Ali pošto program radi nezavisna softverska kuća, njoj je itekako stalo da isti program može da koristi i Ford i Mercedes i zato se ona odlučuje da je konto tipa VARCHAR(20) (za svaki slučaj da ima još mesta) i nema dodatnog CHECK CONSTRAINTA na dužinu konta već će dužinu konta određivati aplikaciju u zavisnosti od podešenog parametra. Na taj način se isti program može ponuditi većem broju kupaca.

Šta se na ovaj način gubi? Gubi se snaga baza podataka u osnovnoj validaciji prosleđenih podataka! Logika o dužini konta se silom prilika iz baze preselila u aplikaciju! Ako se podsetimo da baza treba da bude široko dostupna svakoj aplikaciji koja poželi da je koristi, kako će novo-napravljena aplikacija interpretirati konto dužine 20?! Kako će se ponašati? Koga taj novi programer da pita šta da radi sa takvim monstrumom od tipa?

Da stvar bude još gora - ovde se u priči radi o samo jednoj jedinoj koloni! A takvih VARCHAR(20), VARCHAR(50), VARCHAR(100) kolona ima stotine u složenijim aplikacijama.

I šta onda radi nezavisna softverska kuća? Jednostavno kaže - Ovoj našoj bazi možete da pristupate isključivo upotrebom naše aplikacije! Mi ćemo se potruditi da sprečimo pristup bilo kojoj drugoj aplikaciji, a ako saznamo da ste ipak na neki način upotrebili našu bazu sa nekim drugim programo, tada više ne odgovaramo za podatke u bazi!

Znači ubijen je osnovni smisao postojanja baze podataka, a to je njena dostupnost, i vraćamo se 40 godina u nazad kada je svaki program imamo svoje podatke koje je koristio u svom radu. Upravo je takva situacija dovela do potrebe da se izmisli sistem za DELJENJE podataka.



HUH.... čini mi se da sam se negde izgubio u poentiranju gornjeg teksta, ali mi ne zamerite ;)

Sve u svemu - tržište nas tera da pravimo univerzalne prilagodljive parametrizovane baze i aplikacije iako zdrava logika govori da to nije dobro, jer su takve aplikacije generalno teže za korišćenje i održavanje, podložnije su greškama i sprečavaju slobodu upotrebljivosti pohranjenih podataka.

"The best code is no code at all."
- Zidar (ES član)
"Biggest obstacle to learning
SQL is unlearning procedural
programming."
- Joe
Celko
"Minimize code, maximize data."
- A. Neil Pappalardo
 
Odgovor na temu

Getsbi

Član broj: 124608
Poruke: 2828



+45 Profil

icon Re: Granica izmedju baze i aplikacije27.06.2008. u 05:30 - pre 191 meseci
Lep osvrt na istorijat i dobar tok razmišljanja. Mislim da se nisi izgubio u poentiranju i da je reč “univerzalno” u zadnjem pasusu, (...univerzalne prilagodljive parametrizovane baze i aplikacije..) ključna. Ona donosi večno pitanje: „Koja je mera univerzalnosti?”, “Gde stati sa prohtevima, a ne preterati?“ Mislim da će se u buduće oko toga lomiti koplja.
 
Odgovor na temu

driveM
Novi Sad

Član broj: 152436
Poruke: 31
79.101.66.*



Profil

icon Re: Granica izmedju baze i aplikacije27.06.2008. u 15:24 - pre 191 meseci
Realno, ova tema moze da bude rupa bez dna. Svako ko ima malo vise iskustva je sigurno vise puta primenjivao razlicite "arhitekture" i dosad zakljucio da nije nasao "pravu meru". Verovatno zato sto je i nema!

Jedna krajnost je da pravite glomazno resenje koje treba da bude nezavisno od baze podataka, pa mozda i od aplikacionog servera ili OS-a, i koje trebate da upotrebite (uvalite) na vise mesta a kasnije da ga lako odrzavate - tada verovatno necete moci da drzite "matematiku" u bazi, a verovatno cete i pokusati da upotrebite neki rule engine ne bi ste li satro napravili univerzalno i lako izmenljivo resenje.
Druga krajnost je da imate jednostavnu aplikaciju, mozda cak pisanu u nekom skript jeziku, koja ce uvek trcati na istoj platformi a mozda i custom-made za jednog kupca. Aplikacija moze biti toliko "jednostavna" da je najbrze da na svaki zahtev korisnika odgovorite tako sto cete odmah izmeniti ono sto zahteva - a tada matematika moze biti bilo u bazi bilo u kodu.

Cesto mozete imati privid da "prilagodjavanjem baze" gubite manje vremena nego programiranjem. Istina, iziskuje manje kodiranja, ali ne znaci da iziskuje i manje vremena :-).

Ne znam koliko ste puta nailazili na slucaj da se "trzisni uslovi" toliko cesto menjaju da vi najvise vremena gubite na izmenu poslovnih pravila!? Ja sam to vidjao samo na prezentacijama raznih rule engine-a i business process modeler-a, a u praksi se uvek najvise vremena gubi na GUI, optimizaciju i slicna mesta...
 
Odgovor na temu

deerbeer
Beograd

Član broj: 174418
Poruke: 1189
*.adsl-3.sezampro.yu.



+395 Profil

icon Re: Granica izmedju baze i aplikacije02.07.2008. u 12:32 - pre 191 meseci
Ukratko .. Ne moze se primeniti univerzalan model u programiranju klijent-server programa.
Sta drzati u bazi a sta u aplikaciji ?
Da li praviti klasicnu 2-tier arhitekturu (thin client - fat server) ?
ili 3-tier (client- data layer - database )
ili mozda n-tier (client - data layer & web service - database server )

Imao sam priliku da cujem dosta programera koji razmisljaju na sledeci nacin :
Iskodiram ja to sve u nekom programskom jeziku (C#,Delphi, C++, itd ..) i interfejs i logiku i kalkulacije
(samo zato sto ne voli T-SQL, stored proc i slicno)
a u bazi cu samo da drzim podatke ..ili obratno
a ne razmisljaju kako ce se to posle odrzavati i distribuirati i kakva je fleksibilnost takvog sistema,
koliko se cesto menja logika u aplikaciji ,kakva je infrastruktura mreze gde ce se koristiti program, security politika firme itd ...

Koji sistem ili arhitekturu primeniti sve zavisi od slucaja i od programa koji se pravi...
Ne dajte da vas mnogi zavaravaju sa bussines-rule engine-ima pa da ih po svaku cenu koristite
vec sednete par-dana (ili nedelja zavisi koliki je projekat ) i dobro razmislite o svemu sto vas ceka
pre nego sto napisete i jednu liniju koda ...




Viva lollapalooza
 
Odgovor na temu

darko_sudarov
ProConto Software doo
Kikinda

Član broj: 89262
Poruke: 136
212.200.34.*



Profil

icon Re: Granica izmedju baze i aplikacije03.07.2008. u 08:10 - pre 191 meseci
Najpre zelim da ohrabrim ljude koji ovo citaju - tj ljudima koji su zeleli da kazu nesto ali nisu smogli snage.........

Tema jeste sto bi nas narod rekao cardak ni na nebu ni na zemlji - nit reci sta za, nit reci sta protiv - a da sam sebi
ne protivrecis...ili se prisetis nekog iskustva koje protivreci onome sto bi rekao....
Ali u tome je lepota(barem ja mislim :-) ) ove teme naci kompromis koji ce zaista ispuniti sva tvoja ocekivanja od baze i
programa.
Naci nesto sto zaista po logoci i po prirodi pripada bazi a naravno i aplikaciji.

Takodje da se zahvalim chacki na svarno najboljem postu koji sam oprocitao u zadnje vreme...!!!!Sve sto ja nisam umeo
da objasnim a intuitivno sam osecao on je na pravi nacin objasnio.


Sada da se vratim na temu:

Najpre da obrazlozim dilemu koju u meni stvara pitanje matematike...
Ako je drzim u aplikaciji i dobijem rezultat koji upisujem u bazu to zaista zvuci ok i na prvi pogled sasvim je sve jedno,
ipak aplikacija je mocnija ima vise operacija... -ali u vecini slucajeva (u mom slucaju 100%) ipak se radi o prostoj matemaci..

Oduzmi ovo,saberi sa ovim,podeli sa ovim,sada pomnozi pa mi daj apsolutnu vrednost i to je to!!!
To sve baza moze da uradi...a dali treba?

Evo i zasto mislim da treba-Recimo da su poslovna pravila u aplikaciji i posle izvesnog vremena neko postavi pitanje
validnosti upisanih podataka...
Eto ti muke vadi kod,gledaj sta i kako je racunato,uzmi digitron ...prekucavaj i naravno ...pisi SQL da proveris rezultate!!!

-Predpostavimo da se javila greska-pisi sql da je popravis(ovde aplikacija ne pomaze- ako je jednom pogresila mozda ce i opet!!???-nadjen bug).
nadalje prepravljaj aplikaciju i opet jovo nanovo digitron ....SQL.

-Predpostavimo da greska ne postoji -ipak sam pisao SQL...:-)

Kako god okrenes zavrsi se na SQL-u - pa to je i logicno ja radim sa bazom!!

(Drugi kontra primer bi bio -sta ako imam uredjaj koji ne moze da racuna?Koji samo salje podatke?
E tada aplikacija dolazi u prvi plan - tada je ona ta koja koja ce prihvatiti podatak obraditi ga i prevesti u nesto
ljudima razumljivo i proslediti ga na pravi nacin bazi.E to je po meni prava logika programa - ono sto baza ne ume da program
odradi.)
Da se vratim sa digresije.

Zasto onda ja ne bi poslovna pravila stavio u bazu i u slucaju potrebe samo malo preradio SQL i dobio sve sto mi treba
(i rezultat i kontrolu)?
U slucaju da se isto desilo a da su poslovna pravila u bazi- pa samo bi preradio SQL i pustio ga na svim rekordima.

Ipak je to kraci put koji prsti i zivci treba da predju :-)

Nadalje ako imam poslovna pravila u bazi dali zaista ja time pored navedenog jos nesto dobijam?

Pa naravno-Recimo da istu aplikaciju koriste dve srodne konkurentne firme i jedna od njih radi neki obracun i primenjuje
odradjenu matematiku koje su slicne - zasto bi ja pisao aplikaciju koja u sebi sadrzi oba
nacina rada i proveravala koji se nacin primenjuje?

Sta bi dobio time?
Univerzalniji program?
Po koju cenu?

Setite se samo chackinog primera o tipu polja za konto....(i zaista je u pravu),mislim da baza zasluzuje bolje ostavimo mi
nju na trazenu duzini koja je neophodna za ispravan rad korisnika a sto cemo morati da to isto polje preradimo kod drugog
komitenta... pa sta?Ni prvi ni zadnji put ali zadrzacemo aplikaciju nepromenjenom a komitentu cemo ispuniti zahtev.

Univerzalniji program? E to je tek tema za sebe...Postoji li to uopste?....
Kazu da postoji ali kosta jako puno i implementacija traje po nekoliko godina :-)
Pa po opisu ne lici na univerzalno :-)

Dzaba sve muke ovog sveta i sve pare ovog sveta kada vam neko kaze da nije zadovoljan programom koji ste napisali...
Po meni to je najveca kletva za programera,pogotovo ako volite svoj posao i radite ga srcem(sto je u 99% slucajeva kod ljudi koje poznajem)

Zato to i neradim-nadasve iskustvo me je naucilo da ako neko ima dodatni zahtev najlakse i najbrze je izmeniti bazu...
Ako i ima zahtev obicno se ne zavrsi samo na jednoj stvari - ljudi koji rade za aplikacijom vole da je osete kao svoju...
Da ima ono sto njima treba,da radi onako kako njima godi,da ima dubinu i detaljnost koja njima treba...To jedino baza moze
da im da,aplikacija to ne ume!!!Zasto?Pa zato sto ne ume da upamti koliko i baza.
 
Odgovor na temu

obucina

Član broj: 38191
Poruke: 723

Jabber: obucina


+7 Profil

icon Re: Granica izmedju baze i aplikacije26.07.2008. u 00:23 - pre 190 meseci
Moj predlog, najkraće:

1. U tabele idu samo podaci koji se ne izračunavaju.

2. Izračunavanja raditi u pogledima ili procedurama koje vracaju rezultat.

3. Podaci koji se štampaju kao zvanični dokumenti i moraju uvek biti isti, npr fakture, izračunati, rezultat upisati u posebnu tabelu i štampati ih iz te tabele. NE ŠTAMPATI IZ PODATAKA KOJI SE IZRAČUNAVAJU, UPRAVO ZBOG PROBLEMA SA ZAOKRUŽIVANJEM.


Edit:
Kratak osvrt na chachka i deo o kontima različitih dužina - ovaj problem se može rešiti upotrebom domena, tako da to zapravo i nije problem. U vezi ovoga, u gornju listu bih dodao i

0. Tipove podataka u kolonama UVEK definisati upotrebom domena.
 
Odgovor na temu

srki
Srdjan Mitrovic
Auckland, N.Z.

Član broj: 2237
Poruke: 3654
*.xdsl.xnet.co.nz.



+3 Profil

icon Re: Granica izmedju baze i aplikacije04.10.2008. u 11:57 - pre 188 meseci
Ovo je odlicna tema a meni je zao sto sam bio prezauzet pa se ranije nisam ukljucio. Zahvaljujem se chachki na odgovoru, zaista izvrsna analiza ali ipak se ne slazem u vezi sa mnogim stvarima.

Citat:
chachka: I šta nam ostaje kao izlaz iz ovog problema? Da matematiku obračuna poreza centralizujemo na jedno mesto! Neko će reći - application server koji se obraća bazi dok se ostali programi obraćaju njemu. Ali ovo se kosi sa osnovnom predpostavkom o upotrebljivosti baze, a to je da baza treba da bude dostupna SVIM programima (i to neposredno)!
Zasto? U cemu je razlika ako pristupas stored procedurama ili jednom centralnom application serveru?

Citat:
Naravno bilo bi lepo da neka buduća varijanta SQL standarda definiše i standardizovani "application server" koji bi bio neodvojivi deo samog database servera.
Baze podataka nemaju ni standardizovani jezik za stored procedure i stored procedure na Oraclu mozes da pises u Javi, u .NET ili u PL/SQL.

Citat:
Iz gore iznetog sledi da i moj glas ide da se matematika smešta u bazu
Ali sta ti tacno znaci baza? Podaci + stored procedure? Mozda ce nego drugi reci da je baza podaci + application server, a npr. Oracle pokusava to tako da proda pa u ponudi imaju application server koji tesno radi sa njihovom bazom. Ovo je u vezi sa drugim delom tvoga odgovora pa pre nego sto mi date odgovor na prvi deo (sta je to baza), procitajte drugi deo:

Citat:
Dakle... vraćam se u kraj šezdesetih i početak sedamdesetih godina, u godine kada je nastala ta divna tvorevina zvana relaciona teorija......
...
Vremenom su kompjuteri ulazili u sve više organizacija i firmi i postajali sve jeftiniji, a samim tim je i cena rad programera počela značajno da utiče na troškove firme. Nije više bilo isplativo držati veliki tim programera u okviru firme, te su počele da nastaju i softverske firme koje su nudile svoje usluge.

E takvoj jednoj softverskoj firmi je bina priča o prilagodljivosti njenog programa! Program mora da bude extra fleksibilan da bi softverska firma od njegove eksploatacije imala što veću korist. Naravno ovo je sve više počelo da se kosi sa idejom o relacionoj teoriji jer je ona nastala iz potrebe da se struktuiraju VELIKE količine podataka, a počela je da se primenjuje u sve manjim i manjim projektima, što je neumitno dovelo do njene degradacije i stavljanja u podređeni položaj.

Kao što je Savkić rekao - softverskim kućama je bitno da se njihova baza i aplikacija vrte na raznim database platformama. To znači da takav jedan program nesme da iskorištava pogodnosti koje na primer nudi Oracle u odnosu na recimo PostgreSQL, kao što je na primer upotreba analitičkih funkcija u SELECT naredbama!

To je isto kao da auto Formule 1 vozite kroz grad koji je načičkan semaforima. Bez obzira koliko je taj auto brz, praktična brzina kretanja je 60 km na sat uz naravno povremene bljeskove u ubrzanju, zvuku i zadivljenim pogledima koje ostavljate za sobom.

Slazem se sa ovim, ja volim da iskoristim sve mogucnosti baze i zato ne koristim Hibernate i ORM jer mi nije bitno da mi sistem bude database portable. Bitnije mi je da bude language portable i da bude efikasan.

Citat:
Softver se jednostavno sve manje i manje pravi namenski, a sve više i više se pravi tako da zadovoljava što veći krug klijenata. To praktično znači da će isti softver za obračun sa kooperantima koristiti i u mlečnoj i u duvanskoj industriji uz nekakvu parametrizaciju unutrašnjeg ponašanja softvera.

Da li je ovo dobro? Mislim da nije, i mislim da je zaista svaki problem priča za sebe, i da kao takav zahteva specifični pristup i specifično rešenje. Nažalost, uslovi na tržištu su takvi da je ovakav stav osuđen ili na propast ili na korekciju i popuštanje.
Slazem se sa tobom, ali se u sledecem ne slazem sa tobom....

Citat:
I šta onda radi nezavisna softverska kuća? Jednostavno kaže - Ovoj našoj bazi možete da pristupate isključivo upotrebom naše aplikacije! Mi ćemo se potruditi da sprečimo pristup bilo kojoj drugoj aplikaciji, a ako saznamo da ste ipak na neki način upotrebili našu bazu sa nekim drugim programo, tada više ne odgovaramo za podatke u bazi!

Znači ubijen je osnovni smisao postojanja baze podataka, a to je njena dostupnost, i vraćamo se 40 godina u nazad kada je svaki program imamo svoje podatke koje je koristio u svom radu. Upravo je takva situacija dovela do potrebe da se izmisli sistem za DELJENJE podataka.


Ovde se ne slazem. Zasto mislis da taj program preko koga se pristupa ne bi mogao da se smatra delom baze? Nekad stored procedure nisu ni postojale a sada ako neko napise stored proceduru u Javi to se smatra delom baze. Zasto onda ne bi mogao da koristis neki application server koji pristipa bazi a ostali klijenti koriste tu aplikaciju na application serveru da pristupe bazi? Znaci na application serveru napravis interfejse kao i kod stored procedura ali imas vecu fleksibilnost jer interfejsi mogu da ti budu i web services i native calls itd.. Te web services mogu da koriste razne razlicite aplikacije za koje nije bitno u kom su programskom jeziku pisane (Python, .NET, Java, Ruby itd..). Isto bi i za Stored Procedure mogao da kazes da ubijaju osnovni smsao baze podataka a to je njena dostupnost (ako neko kaze da sme da se pristupa samo preko stored procedures).

Ono sto hocu da kazem je da su pre 40 godina baze cinili samo podaci i tabele a kasnije su se one prosirivale pa se sada i stored procedure smatraju bazom (iako ni tu nemamo standard) a sada se i application server na mnogim mestima smatra delom baze. Kada sam radio u jednoj vecoj firmi onda nam je termin "citati nesto iz baze" u stvari znacio da pristupamo application serveru na kome je aplikacija koja ima interfejs za rad sa bazom.

Citat:
Sve u svemu - tržište nas tera da pravimo univerzalne prilagodljive parametrizovane baze i aplikacije iako zdrava logika govori da to nije dobro, jer su takve aplikacije generalno teže za korišćenje i održavanje, podložnije su greškama i sprečavaju slobodu upotrebljivosti pohranjenih podataka.

Zasto bi Java kod u application serveru bio tezi za odrzavanje nego Java kod u stored proceduri?
 
Odgovor na temu

adopilot
Admir Hodžić
It menager
Sarajevo BiH

Član broj: 123492
Poruke: 134
93.133.138.*

Sajt: nemam ja to


Profil

icon Re: Granica izmedju baze i aplikacije04.10.2008. u 23:24 - pre 188 meseci
Malo je pokasno pa nisam uspijeo pročitati kompletnu temu,
ne da mi đavo mira da idem spavati a da ne odgovorim,
unaprijed se izvinjavam ako nešto ponou avim ili ispadnem iz konteksa
Sa administratorske tačke gledišta;
Uvijek bih inzistirao da da logiga bude smiještena u bazi podatka,
Da se potkrijepim primjerima;

Programeri obično kriju sorce code kao zmija noge od nas krajnih korisniksa, ( stavite vi poslovniu logiku u bazu da mi možemo pregledati kako nešto računate
a ostalo krijte koliko god hoćete)

Aplikacski server su običn bagoviti i nedovoljno razrađeni a kada se još radi o Third partity onda je tu slaba i podrška,
Kod nas u firmi je aplkacion server neka ASTA od tamo nekog proizvođača a data base server je MS SQL e sada zamislite kolo je lakše i bolje raditi i naći
podršku za MS SQL koji ima na milione korisnika naspram neke ASTE koja je pitanje hoće li postojati za 5 godina.

Devloperi obično navode prednosti aplikaciski servera kakao su univerzionalni po pitanju odabira baze (ona priča biraj DB2, Oracle, MS sql, My sql i ostalo)
što za mene baš i nije ni prednost ni isina, Baze se kupuju jednom u životu, Današnji sistemi zahjtevaju replikacije i razno razna čuda koja su opet
specifična za pojedinu bazu, Sam alat održavanja integirteta podataka razlikuje se od baze do baze, što če reči Nemožete napraviti projekat kojem če biti
svejedno za koju se bazu kači. Uvijek če te morati po bazi čeprkati da bi je naštimali za pojedini projekat i aplikacijon server, Onda se tu komplijkuje i verziranje i sve ostalo.

Danas ne postoje toliko jake firme koje mogu zaklopiti sve potrebe jednog jakog klijenta,
Eh sada da bi imali iste procedure i zapise ostavie tu u bazi kako bi mogli i drugi koristiti.

MS Sql bilježi execution plan za svoje STORED PROCEDURE, što je prednos u preformansama u odnosu na modele sa aplikaciskim serverima
koji parsiraju galerije prema bazi bez ikakave veze sa Database serverom.

Skoro uvijek kada radite update verzija programa morate pararelno održavati i bazu podatak (dodavati nove kolone i ostalo) a usput i aplkaciske upite.
Zašto to onda ne bi bilo na jednom mijestu Dosadi to verzija baze je ta, verzija aplikaciskg servera je ta i hoće li sve to raditi.

Seciurity setings i korisniča prava se kompikuju, Ja sada moram jednom korisniku prvo odrediti u application serveru koje menije može vidjeti
pa onda naknadno u sql server štimati dodatna sigurnosne postavke.

Mikrosoft Sql Reporting server radi na principu čvanja kompletne logike u bazi podataka ReportSever baza, Valjda oni u mikrosoftu znaju kako se prave programi.



Ima toga još...
Ali kada se naspavam
Lijep pozdrav
Admir
S poštovanjem
 
Odgovor na temu

[es] :: Baze podataka :: Granica izmedju baze i aplikacije

[ Pregleda: 4584 | Odgovora: 15 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.