DB Abstraction Layer, koji koristite ?

[Ilija Studen]

Znao sam da će Blues ovako odreagovati. Već smo jednom vodili ovakvu diskusiju gde sam ja popustio. Ali sada je moj kung-fu zreliji i bolji

Originalno napisao bluesman

Još kada čujem da nekome treba "abstraction layer" da se nebi petljao sa maysql i kreiranjem querija, onda stvarno ne shvatam kako neko može da se "bakće" sa web programiranjem, piše profesionalne web aplikacije, optimizuje ne samo php kod nego i mysql querije, a da ne želi da se bakće sa mysql.

Nadam se da će ovo ispasti dobar fazon (to je osnovna namera):

Još kad čujem da nekom treba automobil kako se ne bi petljao sa biciklom i pedalanjem onda stvarno ne mogu da shvatim kako neko može da dođe na ideju da krene iz tačke A u tačku B, prelazi taj put uz optimizaciju uloženog truda, a da se ne bakće direktno sa svojim prevoznim sredstvom.

Naravno, biciklo je sasvim dovoljan za većinu svakodnevnih zadataka, ali mi ipak volimo udobnost koju nam automobil pruža, štiti nas od vremenskih nepogoda i uopšteno ulažemo znatno manje sopstvene energije u rešavanje problema. Automobil više troši i skuplji je... Stvari koje smo spremni da oprostimo jer nam zauzvrat pruža dovoljno da opravda te stvari.

Ako treba na brzaka da odletim do obližnje prodavnice sešću na biciklo, ali ako treba da pređem nešto ozbiljniji put onda ću se definitivno odlučiti za auto. Po meni je ovo sasvim logičan način razmišljanja.

---

Tražeći optimalno rešenje za opis podataka sa kojima aplikacija barata našao sam sledeće gradivne objekte:

- sam objekat (korisnik, grupa, vest...) sa svojim svojstvima
- relacije (blog unos ima više komentara, komentar pripada jednom blog unosu)
- validatori (naslov unosa ne sme biti prazan, email adresa mora odgovarati navedenom formatu)

Ono što tebe ne treba da zanima je na koji način će se opisani objekti čuvati (bitno je da budu sačuvani) i kako će se razrešavati relacije među njima. Ono što treba da te zanima je da ti ti objekti budu dostupni i da budu trajni, te da objekat koji sadrži neisprvne podatke ne smeju biti sačuvani (uloga validatora). Klasična crna kutija: ne zanima te šta je unutra dokle god radi ono što si joj ti naložio da radi.

Ako si precizno definisao svojstva objekata, relacije među njima i pravila ti si odradio nekih 70-90% posla. Sve što treba da uradiš je da programiraš izuzetke od opšteg ponašanja i napraviš korisnički interfejs.

Propel ti recimo omogućava da navedena pravila definišeš pomoću jednostavnog XML fajla. Na osnovu njega dobijaš generisane klase, SQL za generisanje konstrukcije baze (u skladu sa platformom), a u fazi razvoja je i mehanizam da dobiješ i gotove forme. 100% free!

Rails ti sa druge strane pravi definiciju analizirajući tabele u bazi podataka dok specifičnosti koje ne može sam da zaključi (validatori, relacije...) definišeš ti unutar model klase pomoću par krajnje jednostavnih komandi. Zauzvrat ćeš čak dobiti potpuno funkcionalan model plus osnovne forme i listanja. Pogađate? 100% free!

---

Za jednostavne stvari se ne ispati dovoditi artiljeriju, ali ako je problem sa kojim se suočavaš iole ozbiljniji zna se. Uštede u vremenu su ogromne, a to znaju osobe koje su radile sa sličnim rešenjima.

Rails važi za ultra produktivno okruženje. Razlog: konvencije, kvalitetan ORM, testiranje, opšte stvari se razrešavaju automatski, programer definiše samo izuzetke. Mislite o tome...

[Pedja]

U principu za svaki projekat pravim zasebam wrapper koji se u sustini sastoji od namenskih funkcija koje izvrsavaju odredjenje upite ili obrade nad tabelama. Tako SQL kod imam samo na jednom mestu, a parametrima funkcija mogu u nekoj meri da uticem na same SQL komande.

Nikad mi se nije desilo da sam menjao bazu na vec gotovoj aplikaciji. U stvari jeste se desilo ali ne sa web aplikacijom.

Naravno da bih voleo da imam mogucnost da samo definisem tabele i relacije a da mi neki "abstraction layer" sam cupa podatke ali nekako mi je nezamislivo da je to izvodljivo a da bude dovoljno jednostavno da opravda trud da se sve to namesti i koristi. Nekako mi ne ide da neki tamo skript moze da sastavi SQL upit koji radi bas ono sto mi treba, a jos manje mi ide da ocekujem da isti SQL upit radi na vise baza, ako ni zbog ceg drugog, ono zbog sitnih nekompatibilnosti SQL komandi kod razlicitih baza.

Sve u svemu, trudim se da SQL kod odvojim od PHP koda, na slicnom principu kao sto se trudim da odvajam aplikacioni od prezentacionog koda aplikacije, ali se uopste ne zanimam mogucnoscu portovanja na drugu bazu.

Voleo bih da vidim neki konkretan primer kako abstrakcioni layer olaksava posao.

[bluesman]

Znao sam da si zbog mene to i napisao, pa sam ti pricinio zadovoljstvo da oprobas ponovo svoj Kung-fu

Igrom slucaja, zbog onih problema ovih dana, bacio sam pogled na recimo www.termomont.co.yu . Proveravao sam sajt online, da li radi i bilo mi je cudno zasto se tako vuce kada je obican html. Mislim, nije obican html, ali moze da bude.

Odmah mi je palo na pamet da je Ilija povukao sav svoj Kung-fu, i opalio iz teskih haubica na ovaj projekat, pa sam morao da zadovoljim znatizelju jer mi je bilo nelogicno da se, tako jedan jednostavan sajt, tako vuce.

Naravno, nisam ni imao nameru da gledam detalje, samo sam pogledao root i video ono sto sam i ocekivao - gomile "layera", raznih "ja ne volim bicikl" klasa, jednostavno kao da si skinuo sacmaru sa zida da ubijes komarca.

Kao što sam ti onomad rekao, imaćeš jako ozbiljan problem kada budeš uradio neki sajt na koji će se kačiti gomila ljudi pa ćeš imati i po 100 query-ja u sekundi. Ako i preživi sajt, vući će se maksimalno....

A sve to zato što sedaš u auto i kada ideš u toalet.

[Ilija Studen]

Originalno napisao Pedja

Naravno da bih voleo da imam mogucnost da samo definisem tabele i relacije a da mi neki "abstraction layer" sam cupa podatke ali nekako mi je nezamislivo da je to izvodljivo a da bude dovoljno jednostavno da opravda trud da se sve to namesti i koristi. Nekako mi ne ide da neki tamo skript moze da sastavi SQL upit koji radi bas ono sto mi treba, a jos manje mi ide da ocekujem da isti SQL upit radi na vise baza, ako ni zbog ceg drugog, ono zbog sitnih nekompatibilnosti SQL komandi kod razlicitih baza.

Lista biblioteka koje rade baš to

---

www.termomont.co.yu - da ne dužim priču i odlazim u offtopic: sajt je takav kakva je s dobrim razlogom. Speed king nije, ali nije ni spor koliko vidim.

[bluesman]

Samo bih voleo da mi neko pokaže jedan abstraction layer, ili kako god ih već zovete, koji će za jednu dobro normalizovanu bazu da napiše query sa 2-3 join-a.

Znam da će ilija da kaže da se to piše ručno, ali sorry, ako mi treba "abs layer" da ne bih pisao "SELECT * FROM USERS LIMIT 10" onda mi takav Kung-fu ne treba. Znaci, otpada prica o "crnoj kutiji" koja radi savrseno a ti samo sedis i vozis (naravno sa proturenim laktom kroz prozor)

[ivanhoe]

da, ja sam i poceo pricu upravo zato sto ja volim da radim direktno sa SQL-om, pa pretvaranje SQL upita u komplikovan poziv metoda nekog objekta kreiranog unapred ne vidim kao neku veliku ustedu vremena, a meni to smanjuje jasnocu koda... pogotovo ako se jos koristi i neki custom wrapper oko toga, onda neki jadnik koji treba da gleda moj kod nema nikakve sanse da brzo shvati o cemu se radi u kodu...

naravno to je sve pitanje navike...

[Ilija Studen]

Originalno napisao bluesman

Samo bih voleo da mi neko pokaže jedan abstraction layer, ili kako god ih već zovete, koji će za jednu dobro normalizovanu bazu da napiše query sa 2-3 join-a.

Kao što već rekoh, sistem radi opšte stvari, izuzeci su na programeru. Statstički gledano, odnost "jednostavnih" operacije tipa:

PHP kôd:

// Primer čija je jedina svrha da pokaže kako izgledaju zahtevi!
$user = UserPeer::retreiveByPk(12);
$group = $user->getGroup();
if($group instanceof Group) {
  $all_users = $group->getUsers();
} 


su daleko (sa naglaskom na daleko) brojnije od kompleksnih upita. Propel ima kompletnu podršku za JOINove kroz Criteria klasu, a u generisanim klasama dobijaš metode za brzo izvršavanje JOIN upita nad tableama među kojima su relacije poznate. Do koje kompleksnosti upita možeš da ideš sa Criteria klasom možeš da saznaš ako postaviš pitanje na Propel mailing listi.

Slično je i sa ActiveRecordom (Rails), s tim da je osnovna poenta kod Railsa "less everything" tako da su malo "štedeli" na podršci za stvari koje se koriste u jako retkim situacijama te samo "zagađuju" kod nepotrebnim stvarima.

Ja sam svoje argumente izneo. Kao neko ko je koristio oba metoda (sa i bez slojeva kao što je Propel) kažem da ti slojevi uz uglavnom zanemarljiv pad performansi donose veću produktivnost, sigurnije i robusnije aplikacije koje se lakše održavaju. Ko se ne slaže nek proba da argumentovano dokaže suprotno

PS: Blues, verbalni terorizam: cepidlačenje i hvatanje za sitnice

[bluesman]

Moraš da paziš šta govoriš kada pričaš sa mnom

Ma nije, nego kada navedeš primere, pa ih još bolduješ, ja baš volim da upotrebim tvoje primere da dokažem svoje.

Pazi, ako ću ja da definišem "kriterijume", koristim 66 klasa i 20-ak include da bih napisao jedan JOIN koji mogu iz glave da sastavim onoliko brzo koliko mi daktilografksa sposobnost dozvoljava, onda ću rađe da propustim te "fensi" stvari.

A što se argumenata tiče, pa ja ti baš malo pre dokazah suprotno. Mada, ne očekujem da ćeš ih prihvatiti, poučen prethodnim iskustvima

Evo neka ti pokaže nixa, meni je pokazivao pre neki dan, kako radi frog design. Čuo si za njih? To ti je jedna od jačih globalnih web design firmi. Imaju klijente koji barataju milionima dolara kao klinci "Yu-Gi-Oh!" sličicama (ko ima decu, shvatiće )... pa da vidiš kakav kod im proizvode. Ceo sajt <table></table>, nikakve fensi munje... Da to postuješ negde kod nas na forumu, popljuvali bi te u roku od odmah uz komentar "ništa ne valja, koristiš tabele".

[bluesman]

Moram da nađem neki primer. Koliko se sećam ti si mi pokazivao neke glavne "features" tih layera kao što su na primer generisanje klasa za svaki objekat iz baze.

Generiše se klasa koja ima funkcije tipa:
->getId ()
->setId ()

koja ništa drugo ne radi nego čita iz records polje Id .

Pa onda tako za svaku kolonu iz tabele imaš po jednu get i jednu set funkciju.

Sorry, but this is just plain stupid

[Pedja]

Ako sam dobro razumeo mi i jedni i drugi na kraju imamo skup funkcija/klasa/metoda koje rade isti posao. Neke su napisane rucno, neke automatski generisane iz opisa modela baze ali je na kraju rezultat isti.

Jedino sto ne valja u celoj prici to je ako neko mesa SQL i PHP, to jest, pise SQL onde gde mu u PHP-u zatreba umesto da pravi odvojene funkcije sa evenutalno uopstenim parametrima.

Onda je prednost abstraction layer pristupa samo u tome sto on sam izgenerise dobar deo koda. Losa stvar je sto zbog uopstavanja verovatno generise kod koji nije toliko optimalan kao kada bi bio napisan rucno.

Ne bi bilo tesko napraviti php skript koji za postojecu tabelu, pa cak i opisane relacije izgenerisao php funkcije koje rade standardne operacije nad tabelama i to bi verovatno radilo bolje nego klasa koja u letu kreira kod/upit koji treba da izvrsi.