DB Abstraction Layer, koji koristite ?

[ivanhoe]

Originalno napisao degojs

Onda i pričamo o istoj stvari. Ostaje da vidimo kako ivanhoe radi ovo isto

kul je ovaj JSP...
Mada ovaj tvoj priemr je vise zgodan zbog validacije forme, nego sto je nesto velika usteda oko inserta...a koliko je meni u znanju ni jedan DB abstraction za php4 ne nudi nista na ovu foru...

a sto se tice toga kako ja to radim, ja uglavnom koristim php i mada ima u php-u brdo gotovih klasa za validaciju, ja to obicno radim od slucaja do slucaja, jer mi retko treba vise od 10-tak polja po formi, a za to copy&paste radi posao... a sem toga ionako neka malo slozenija pravila kao validaciju email-a, CC-a ili zip kodova moras da pises rucno...

a sam insert sam vec jednom pisao, otprilike ovako:

PHP kôd:

$err_arr = validate(); //validacija forme
if( !is_array($err_arr))
      $db->insert('ime_tabele', $_POST); // insert 


umesto $_POST moze bilo koji hash kome su kljucevi imena polja u bazi...tvoje java resenje jeste krace i lepse, ali nije to bas tako strasno komplikovano ni ovako...naravno da moram da obradim 50+ polja po formi verovatno bi mi dobro dosao neki Pear DB_Data_Object ili Propel ili vec neka teska artiljerija...


i da se razumemo nemam ja nista protiv fancy DB abstraction layera, bas naprotiv ja bih rado da uzmem da koristim neki dobar (jer ovo sto ja koristim datira jos iz php3 i sigurno moze bolje da se odradi), ali mi smeta kod vecine sto su preglomazni, a pritom pola opcija koje nude mi ne trebaju. Ja bih neki jednostavan, brz, a funkcionalan... koristiti ove postojece na obicnim sajtovima je kao voziti porshea po beogradu, neces moci da primetis neku realnu prednost, osim sto je fancy i trosi vise..

Cisto kao mali primer moje logike, na sajtu AdoDB Lite mozete da vidite benchmarke koji pokazuju da je AdoDB oko 5 puta sporiji od cistog mysql-a (bez akceleratora, ali to je uobicajen slucaj)... a plus zauzme nekih 700KB memorije samo kad se includuje...to nije bas zanemarljiva stvar, priznacete?

[Ilija Studen]

Originalno napisao ivanhoe

DB abstraction za php4 ne nudi nista na ovu foru...

CakePHP bi trebalo da ima relativno kompletno implementiran ActiveRecord sa validatorima što znači da se generisanje i validacija formi rade (polu)automatski. U Railsu (Cake je pravljen po uzoru na njega) je sve automatizovano tako da je pitanje koliko su phpnut i kompanija (CakePHP dev tim) dogurali u portovanje.

U Propelu (PHP4 i PHP5 generator) imaš mogućnost setovanja validatora (sprečavaju insertovanje / update objekta sa neispravnim svojstvima), ali ne i podršku za automatsko generisanje / procesiranje formi. To moraš sam da implementiraš ili možeš da "pokradeš" neko gotovo rešenje kao što je Symphony na primer.

Originalno napisao ivanoe

ali mi smeta kod vecine sto su preglomazni, a pritom pola opcija koje nude mi ne trebaju

Slažem se. Zato i volim Rails... Uzeli su less everything pristup tako da je sam framework nezagađen. Ima ono što ti treba i nešto sitno preko. Tu se staje... Kamo sreće da ekipa koja radi Propel prihvati ovaj pridtup.

Čak iako sam nezadovoljan kvalitetom mnogih PHP5 rešenja ipak branim stav da je pametnije koristiti ovakve biblioteke nego se igrati sa čistim SQLom kod svih složenijih projekata. Za sitne stvari quick and dirty, za ozbilnije zna se...

---

Pošto je bluesman izjavio da većina koristi ovakve biblioteke kako ne bi morali da koriste SQL iz razloga što ga ne znaju (ovu izjavu u najmanju ruku smatram netačnom) evo malo istorije.

Prvi Windows programeri su morali da znaju Win32 API u dušu da bi radili. Pišu ljudi koji su radili u to vreme da je to jedan izuzetno komplikovan i smoran posao. Nisam probao tako da moram da im verujem na reč. Kako je vreme prolazilo, tako su alati sazrevali da bi danas koristio proste drag and drop metode za kreiranje formi, gotove biblioteke za rad sa prozorima i kontrolama itd itd itd. Sam API retko ko koristi, sve se radi kroz wrappere. Možda grešim u nekim detaljima, nisam se bavio programiranjem u to vreme tako da mogu da pričam iz prve ruke. Samo želim da istaknem da se programiranje razvija u tom smeru da skraćuje vreme koje programer treba da uloži u prljav, vodoinstalaterski posao (jer SQL to uglavnom jeste) i omogući mu da se više koncentriše na konkretan problem koji treba da reši, stvari unikatne za projekat.

Slična stvar se desila i sa SQLom na ozbiljnim platformama (.NET, Java, Delphi...), a polako niču projekti koji portuju rešenja sa tih platformi (Propel je u suštini PHP verzija Torque projekta) ili osmišljavaju i implementiraju nova na "neozbiljnim" platformama.

---

Ne znam da li da pokazujem jedan jednostavan Rails primer pošto mislim da je kod njega iskorišćen jedan od lepših pristupa? ActiveRecord je stvarno lepo napravljen.

[zextra]

Off Topic: Retko dobra diskusija. thumbs up!

[ivanhoe]

Originalno napisao Ilija Studen

Samo želim da istaknem da se programiranje razvija u tom smeru da skraćuje vreme koje programer treba da uloži u prljav, vodoinstalaterski posao (jer SQL to uglavnom jeste) i omogući mu da se više koncentriše na konkretan problem koji treba da reši, stvari unikatne za projekat.

Slična stvar se desila i sa SQLom na ozbiljnim platformama (.NET, Java, Delphi...), a polako niču projekti koji portuju rešenja sa tih platformi (Propel je u suštini PHP verzija Torque projekta) ili osmišljavaju i implementiraju nova na "neozbiljnim" platformama.

Ja sam ranije radio dosta u Delphiju (a cini mi se da se i Pedje secam sa yu.prog.delphi newsa? ) i apsolutno podrzavam taj vid automatizacije koji recimo Delphi pruza. Dovuces par komponenti, popunis par propertija i imas npr potpuno funkcionalni data-grid. Dajte mi to za php i bicu srecan kao kuce, pa makar morao da pozivam objekte da uradim SELECT *...

Ali Delphi ti takodje nudi mogucnost i da stvari radis na vrlo niskom nivou, ako treba i asembler da koristis... autori ovih DB klasa koje sam ja imao prilike da vidim ne omogucavaju low-level alternativu i to je po meni problem..

Nije samo da je ponekad naprosto brze i lakse otkucati par sql komandi... ponekad (cak prilicno cesto) je prakticno neophodno iskoristiti neku specificnu foru baze koja zahteva kontrolu koju pruza SQL...

Uzmi recimo "SELECT SQL_CALC_FOUND_ROWS ..." i "SELECT FOUND_ROWS()". Jako korisna stvar da izbegnes dupli upit na bazi kad koristis limit da prikazes samo deo rezultata (paged results), sto ce reci prakticno na svakoj strani gde se nesto lista iz baze. Sa pre-generisanim klasama si osudjen na 2 upita, jedan count(*) i jedan sa limitom...

Ili mozda i kriticnije, cinjenica da kod mysql-a ponekad zavisi koji ce index da se upotrebi (i da li ce se uopste upotrebiti) od redosleda uslova u WHERE klauzuli (to je po meni zapravo bug u query optimizeru, ali sta da se radi..). Kako ces to da kontrolises, ako ti klasa to pravi automatski i jos ti prepakuje tvoj SQL da bude kompatibilan sa 20 drugih baza?


to je jedna vrsta problema, mozda ne toliko bitna za generalnu publiku, jedan upit ili 5 tesko da je bitno, recimo prosecna strana bloga u Wordpressu uradi 30+ upita i opet ga svi srecno koriste (ukljucujuci i mene jer sam lenj..)

drugi ocigledniji problem (koji i mene muci priznajem) je naravno da je potrebno promeniti nacin razmisljanja o bazi za 90 stepeni, sto bas i nije jednostavno ako radis na odredjeni nacin godinama... za mene je SQL najprirodniji nacin obracanja bazi, jer sam tako naucio.. Da sam prethodno radio sa OO pristupom bazi (sto cenim da je po godinama slucaj sa Ilijom) verovatno bi mi se to cinilo kao super stvar u odnosu na kuckanje SQL-a... navika je mnogo gadna stvar...

ja za sada jos uvek skidam i isprobavam razna resenja, cekam nesto sto ce da napravi kompromis izmedju lakoce rada i mogucnosti...we'll see...

[bojan_bozovic]

Nisam koristio DB abstractiol layer. SQL? Pa to je jednostavno! Ne znam, ne volim da komplikujem kad moze jednostavno. BTW i performanse su mi bitne, sto se debagovanja SQL tice, samo udrim $querydump=$querydump." ". $query; pri svakom upitu i na kraju echo $querydump i imam i vise debagovanja nego sto mi treba Ne znam zasto da se mucim sa ko zna koliko komplikovanom bibliotekom za vrlo jednostavne stvari. Mozda, da moram da migriram na drugu bazu, ali je to sigurno vrlo pipavo, i opet bih zeleo da to redim rucno. Nemam onda tudji (citaj: bagovit) kod izmedju. Gresim li ja nesto ili je pravjenje XML za DB abstraction lejer isto sto i rucno dizajniranje baze? BTW mislim da je bolje da covek dizajnira bazu nego da imas 80 tabela u potpuno normalizovanom stanju ili sta vec glupi kompjuter moze da napravi. Kompjuter ne poseduje inteligenciju da me zameni u poslu, pa dali sam pravim CREATE upit za tabelu ili to pisem u XML, isto bi trebalo da bude.

PS: Kad moj kod zabrlja, bar znam sta je i gde je. Sa tudjim kodom nije tako, jer nemam dokumentaciju za kod.

[degojs]

Poceli smo i da se ispovedamo, a

ivanhoe:
Nije samo da je ponekad naprosto brze i lakse otkucati par sql komandi... ponekad (cak prilicno cesto) je prakticno neophodno iskoristiti neku specificnu foru baze koja zahteva kontrolu koju pruza SQL...

Uzmi recimo "SELECT SQL_CALC_FOUND_ROWS ..." i "SELECT FOUND_ROWS()". Jako korisna stvar da izbegnes dupli upit na bazi kad koristis limit da prikazes samo deo rezultata (paged results), sto ce reci prakticno na svakoj strani gde se nesto lista iz baze. Sa pre-generisanim klasama si osudjen na 2 upita, jedan count(*) i jedan sa limitom...

Nije to problem. Svaki bolji generator daje, je li, sors kod. A ti ga posle izmeni kako hoces. Jos bolje, izmeni sablon, tako da u jednom cugu dobijes rezultate vise upita.
Npr. Java to podrzava bez problema. Vise upita, jedna komunikacija sa bazom, dobijes kolekciju ResultSet-a nazad. Nema problema.

Kako ces to da kontrolises, ako ti klasa to pravi automatski i jos ti prepakuje tvoj SQL da bude kompatibilan sa 20 drugih baza?

Pazi, ovo sto mi koristimo ne daje kod koji moze da radi sa 20 baza "istovremeno", nego kod koji radi sa jednom bazom. Ali ti mozes lako da kazes hocu sad kod za tu drugu bazu pa za 30 sekundi, eto ti koda (optimizovanog) za drugu bazu. Stvar je da kod svoje aplikacije ne moras da menjas.

drugi ocigledniji problem (koji i mene muci priznajem) je naravno da je potrebno promeniti nacin razmisljanja o bazi za 90 stepeni, sto bas i nije jednostavno ako radis na odredjeni nacin godinama... za mene je SQL najprirodniji nacin obracanja bazi, jer sam tako naucio.. Da sam prethodno radio sa OO pristupom bazi (sto cenim da je po godinama slucaj sa Ilijom) verovatno bi mi se to cinilo kao super stvar u odnosu na kuckanje SQL-a... navika je mnogo gadna stvar...

Ajd sad kad vec pricamo..

Nije tu samo to problem. Kod takvog pristupa dosta vremena ode na pocetku na dizajniranje klasa i odnosa medju njima, interfejsi, nasledjivanje.. a to znaci da vidljivih rezultata nema tako brzo. A samim tim ako sve to moras da radis skoro je sigurno da je veliki projekat u pitanju. Pitanje je da li tvoj projekat uopste spada u tu kategoriju.

Sa druge strane, bazu je uglavnom lako uraditi (pogotovo ako ti bluesman ne radi normalizaciju nakon sto si ti normalizovao pa denormalizovao istu ) i mozes da krenes sa front-endom (pogotovo ako imas dobar alat koji ce da ti ustedi sav vodoinstalaterski rad na relaciji front-end <-> baza). I rezultati, makar rada u toku, su brzo vidljivi, a to se cesto jos i trazi.

Mozda ce da bude drugacije kad jos i baze budu podrazumevano nudile tipove podataka a la java.Object, net.Object, php.Object i slicno..

"Doh!" sto bi rekao dinke, ovaj, Homer Simpson.