DB Abstraction Layer, koji koristite ?
 

i da li uospte koristite neki ? :)

Jako se mnogo prica o portabilnosti koda sa jedne baze na drugu, ali nisam siguran koliko to prakticno ima znacaja? Da li vam se ikada desilo da ste naknadno morali da portujete neki web projekat sa jedne baze na drugu?

AFAIK za vecinu web sajtova se sa 99% sigurnosti moze tvrditi da mysql moze da odradi mnogo vise nego sto ce im ikada trebati, pa mi se sva ta prica o portabilnosti cini vise kao hip, nego kao real world potreba...a i koliko god dobra bila klasa, prelaz sa jedne baze na drugu je uvek mnogo vise gnjavaze od proste promene par parametara....

Koje je vase misljenje o tome da li se isplati koristiti abstraction layere uopste?

ti paket ubrzavaju razvoj, i omogucavaju cistiji kod, sto je svakako plus...ali opet vecina njih (recimo Pear:DB ili AdoDB za PHP) imaju gomilu dodatnog koda koji se izvrsava da bi osigurao da SQL upit bude portabilan medju bazama, a ako cu ja koristiti samo npr. mysql to je cisto trosenje resursa. Takodje upotrebom tih klasa postaje relativno komplikovano izvesti neke specificne cake vezane za konkretnu bazu, a koje bi mogle da ubrzaju stvari (npr. jako zgodna auto inkrement polja u mysql..)

Kakva su vasa iskustva?

Ja koristim Propel, a on kao abstraction layer koristio Creole. Dobra stvar je što zajedno omogućavaju vrhunsku portabilnost jer te ne zanima koja je baza ispod. Definišeš koje objekte želiš, kako su povezani i na osnovu toga se za konkretnu platformu generišu konstrukcija baze, klase, relacije među njima... Konstrukcija je u XML formatu tako da je nezavisna od platforme.

Problemi:

- Generiše se mnogo koda
- Potrebno dosta vremena da se sav taj kod parsira tako da je distribucija u izvornom obliku ludost. U produkciji je najpametnije koristiti enkodirane fajlove jer se tu preskače parsiranje. Takođe, pametnim korišćenjem __autoload() funkcije se isto mogu ostaviriti uštede...
- Ovakav kod jeste sporiji, ali u ekodiranom obliku uštede u performansama su zanemarljive u odnosu na dobijeno vreme u razvoju / portovanju (hardver - jeftin, vreme dobrog programera - skupo). Ko je bar jednom koristio nešto slično zna o čemu pričam. Ostali samo mogu da nagađaju ;)
- Nije za male projekte

Ukolike je projekat bar malo složen (5 tabela +) i nisu potrebne maksimalne performanse (ovde mislim na stvarno ekstremnu posećenost) uvek preporučujem korišćenje abstrakcionih slojeva. Ubrzavaju razvoj, povećavaju portabilnost koda i pomažu ti da umesto da razmišljaš o tabelama u bazi i poljima razmišljaš o objektima, njihovim relacijama i konkretnim problemima koje treba da rešiš.

PS: Do sada nisam bio u situaciji da moram da portujem kod na drugi tip baze. Lakoća portovanja nije osnovni razlog zašto bi se neko odlučio na korišćenje ovakvih biblioteka. Jednostavno olakšavaju i ubrzavaju rad, a portabilnost mu tu dođe kao fin dodatak.

Home made db wrapper mi radi posao. Jos uvek nisam imao realnu potrebu da koristim drugi db engine, osim mysql...

Inace, na phpclasses.org se bukvalno svaki dan pojavi novi mysql wrapper, ponekad i po dva komada :)

Ja u principu do sada nisam koristio nikakav DB abstraction layer, niti sam se susreo sa potrebom da moram da prebacujem kod sa jedne baze na drugu. SQL pisem sam, a koristim jednostavan OOP MySQL API koji sam sam razvio. Ovih dana prelazim i ja na PHP 5 (i to odmah 5.1) pa cu probati PDO ako stignem.

I ja sam od onih koji smatraju da je koriscenje biblioteka tipa PEAR::DB kada to nije apsolutno neophodno uludo trosenje resursa.

ADOdb (za manje projekte ADOdb Lite)

Zaboravih da napomenem, a možda iz mog posta nije očigledno.

Mislim da je apstrakcija baze podataka polukorak. Nešto što nema puno smisla... Možda u tolikoj meri da je definisan standardan API i par pomoćnih metoda koji sprečavaju fizikalisanje. Dalje od toga je uludo trošenje resursa.

Međutim apstrakcija kompletnog pristupa podacima ima znatno više smisla po meni. To je kompletan korak, kad ne morate da pišete SQL i razmišljate o bazi. Jedan od slučajeva je da se ispod klasa i ne nalazi baza već možda XML fajl. Sama aplikacija toga nije svesna (i ne bi treba da bude). Njoj je bitno da do podataka dođe, a na koji način će se oni "očuvati" između zahteva treba da prepusti potpuno automatizovanom sloju.

Problem i rešenje fino opisani ovde...

Da, zato se jedno zove wrapper, a drugo abstraction layer, zar ne?

Koristim ezSQL wrapper (pokupio ga sa phpclasses), za sitnije sajtove koje sam radio - sasvim ok. Ne verujem da će bilo koji od tih sajtova prelaziti na neke egzotične baze, tako da mi nije bila potrebna nikakva apstrakcija, a i volim direktno da pričam sa bazom :D

Ah da, ima i sjajnu funkciju za debugovanje queryja.

Da ne bude da kvarim žurku... koliko vas je imalo priliku da menja bazu podataka na nekom projektu pa da mora da ima dobar "abstraction layer", koliko vas je uopšte započelo sa jednom bazom a završilo sa drugom, koliko vas je uopšte radilo bilo šta drugo osim mysql i ponekad pgsql?

A da ne govorimo da obično takve stvari utiču na performanse, naročito na sajtovima sa većim brojem poseta.

Ja imam jednu svoju klasu za rad sa mysql, i samo je dorađujem godinama... klasa je napravljena tako da mi olakšava rad sa smarty, najviše zbog assign, radi u PHP3, 4 i 5, i iskreno nikada mi nije trebalo ništa više od toga.

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.

Koliko sam ja razumeo, radi se o radu sa objektima umesto sa zivim podacima i sakrivanju istih od programera, sto omogucava apstrakciju na visokom nivou, npr. za potpuno dinamicke aplikacije (CMS frameworks?)...

Kao sto sam vec rekao, nista bolje od rucnog sastavljanja querija i obrade istih u 2-dimensional array :)

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

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

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.

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.

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.

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

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

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

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

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

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

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

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.

sta ima toliko lose u mesanju SQL-a i PHP-a ?
pa nije to html pa da pises pasuse texta, SQL su skoro uvek one-linersi, a onom ko gleda kod (pod uslovom da zna SQL naravno) je mnogo jasnije o cemu se radi, ako vidi ceo upit...

recimo u mojoj obradi phpLib biblioteke upit izgleda ovako nekako:
$db je objekat koji se sam poveze na bazu, hvata greske i radi escape promenjivih.....mislim da je to sasvim dovoljno jednostavno, da mi neka dalja apstrakcija apsolutno ne treba. Naravno za neke stvari koje se cesto rade, ok je odraditi zasebnu funkciju da se izbegne pisanje istih upita, tipa:
ali bas da mora svaki SQL upit da se sakrije u funkciju, mislim da ne mora...

U osnovnoj liniji da. Ima tu par dodatnih prednosti kao što je odvajanje aplikacije od skladištenja podataka, ugrađeni mehanizmi za keširanje itd.

getX() i setX($value)

Jedna od osnovnih osobina objektno orijentisanog programiranja je enkpsulacija. Ne znam za vas, ali po meni su podaci iz baze podataka sirovi podaci, polufabrikat. Metodi koji omogućavaju pristup ovim podacima (get i set metodi koje blues navodi) pripremaju podatke za korišenje u skriptu, a najtrivijalniji posao koji rade je casteovanje u odgovarajući tip.

Primer kada ovo stvarno dobro dođe smo već imali prilike da vidmo: upgrade baze na Host011 i problem sa TIMESTAMP poljem. Frustracija je bila tolika da je kao rešenje iskorišćen drugi (čistunci bi rekli pogrešan) tip podataka, a jedan od koraka u rešavanju problema je ubijanje nekog odgovornog u MySQLu.

E sad, da je korišćen neki apstrakcioni layer bilo bi dovoljno promeniti način na koji sloj barata sa tim tipom polja na jednom, eventulano dva mesta (unutar baznih klasa) i sve aplikacije koje koriste datu biblioteku ne bi imale nikakvih problema u novom okruženju. Radi kao da se ništa nije ni desilo ;)

Možda sam ja čistunac, ali volim da iz INT kolone dobije integer, iz DATETIME kolone dobije ili timestamp (INT) ili formatirano vreme (proslediš format getteru), iz BOOL kolone dobijem samo TRUE ili FALSE....

Svedi na teoriju programiranja i videćeš da direktan pristup sirovim podacima bez prethodne obrade, međurezulatatima itd predstavlja loš dizajn. Malopre sam naveo i svež primer zašto.

Za nostalgičare

Ako se nekom ne sviđa da koristi $user->getId() implementiranjem ArrayAccess interfejsa moguće je napraviti da se objekat tretira kao niz, te da bude izvodljivo:

Potpuno čisto OO rešenje za ljude zaljubljene u nizove.

- ako SQL izmesas sa PHP kodom, pa naknadno dodje do neke izmene u strukturi ili nacinu obrade, moras da trazis po kodu gde si sve ubacivao upite na koji se te izmene odnose

- SQL cesto nije oneliner, a i ako jeste, obicno ima bar neki promenljivi deo, pa SQL upit u stvari sastavljas u letu, korsiteci PHP, sto je odmh i necitkije. To je bolje odvojiti u zasebnu funkciju, kojoj prosledjujes potrebne parametre, jer tako cinis kod citkijim. Inace sebi pravis veliku komplikaciju koja se nadovezuje na prethodni stav

- Murphy: ako u kodu upotrebis SQL upit na jednom mestu, sasvim je sigurno da ces ga upotrebiti na najmanje jos jednom

- Zlatno pravilo programiranja je pravilo uopstavanja problema. Ma koliko imao ociglednu situaciju koju treba da resis, sasvim je uputno gledati je sire i napraviti kod koji mozes da iskorsitis i u drugim situacijama. Za tvoj primer, recimo, sasvim je logicno napraviti mogucnost da parametrima odredis redosled slogova, broj slogova koji se izvlace iz tabele pa cak i filter jer to ne moze da ti ne zatreba.

Mislim da je ova tema pokrenuta sa stavom da nije pitanje treba li koristiti neki wrapper, nego sta i kako koristiti. Ne valja se vracati unazad, na nacin programiranja od pre procedura i objekata.

Tvoj primer je u neku ruku neobican, jer jedan problem resavas objektnim pristupom, koji je i nastao iz potrebe da se kod pise modularno, uopsteno i da bude upotrebljiv u raznim situacijama a sa druge strane sve te principe potires mesanjem SQL-a direktno u celu pricu.

Naravno, i sam kazes da ovo radi kada su u pitanju jednostavni poslovi, a siguran sam da svako od nas ne preza da ovako napise neki privremeni skript, jer je brze i ociglednije, ali, ako pises kod koji treba da bude u upotrebi dugo vremena, treba da ga odrzavas (ili jos gore, da ga odrzava neko drugi), mesanje SQL-a u PHP je medvedja usluga.

Hm, Django ORM?
Primere modela možeš naći ovde, od kojih bih izdvojio many-to-many, rekurzivnu many-to-one relaciju na samoga sebe, i veoma fin primer implementacije category modela koji možeš koristiti u svojim aplikacijama.

A sam db-api će postati znatno lepši kada "magic-removal" grana bude stabilizovana i uključena u osnovnu distribuciju.

@Ilija vezano sa accessor metode: Jedna od razloga zašto mi se PHP kao jezik/platforma ne dopada je što nema property-e. Umesto ručno pravljenih metoda object.getMember() i object.setMember(value) lepše/lakše/bolje je koristiti property object.member.

Ovde si potpuno u pravu. I sam sam navikao na objektni pristup, i razmisljam kako bi bilo lepo napraviti klasu, na primer, komitenti, koja ima sve sto moze da ti zatreba vezano za entitet komitent iz baze. U stvari tu klasu ne vidim kao wraper za tabelu komitenti nego nesto vise kao wraper na view nad tabelom komitenti i svim ostalim tabelama koje su sa njom vezane. Medutim, pisati tako nesto je poprilican posao tako da se nikad nisam prihvatio toga da takav mehanizam realizujem.

S druge strane, gledao sam neka resenja kao sto su i ova nesto ranije preporucena, ali mi to sve nekako deluje previse apstraktno, i previse me odvaja od samih podataka. Verovatno kada bih sam napisao nesto takvo, onda bih imao mnogo manji problem sa apstraktoscu.

Ali slazem se, to je definitivno pravac u kome treba razmisljati.

pa ok, apsolutno se slazem da treba koristiti db layere, ali pitanje je upravo sta ocekujes da ti layeri rade? Znaci ne samo koji koristiti, nego i zasto bas taj...

Ovaj kod sto sam ja naveo je isto tako vid apstrakcije baze, jedino sto se ne petlja u rad sa samim SQL-om, nego se koncentrise iskljucivo na podrsku propratnih akcija (provere da li vec postoji konekcija, escape parametara u upitu, hvatanje gresaka, free results, debug, konverzija nekih tipova (nrp. timestamp u unix timestamp) i slicno..). Svestan sam da je ovo prilicno konzervativan pristup u odnosu na danasnje trendove, zato sam uostalom i poceo ovu temu...Meni se AdoDB recimo dopao, a svidja mi se i Pear: DB_Data_Object kako radi, ali imam problem da nisam siguran koliko takav visoko apstraktni pristup meni stvarno treba, u poredjenju sa ovom umerenijom apstrakcijom koju sad koristim...

Osnovni problem kod pokusaja da se proces generalizuje (sto je naravno dobra stvar) po mom iskustvu je sto u nekom trenutku funkcija/klasa koju pises pocne da bude preterano komplikovana da bi podrzala svih 200 miliona specificnosti koji mogu da se dese... Ili drugi pristup je da pravis specificnu metodu za svaki taj slucaj, a onda zavrsis sa toliko metoda (obicno slicnih imena) da vise covek ne moze da se seti kad sta koristiti, a one sede u kodu, trose meoriju i skupljaju prasinu...

Mislim da je glavna fora efektivnog programiranja da se oceni kad treba stati sa "uopstavanjem" i neke stvari ostaviti namerno nepokrivenim, jer su retke, a dovele bi do "viska" koda... Najprostiji primer ov logike je ona insert metoda sto sam naveo u proslom postu, ona je super za obicne inserte, das joj niz podataka i ime tabele i ona ih ubaci. E sad sta ako treba umesto konkretne vrednosti ubaciti mysql funkciju (recimo NOW() ), sto cak i nije toliko redak slucaj? To namerno nije podrzano, mada verovatno ne bi bilo komplikovano smisliti dodatni parametar ili regExpom proveriti da li je parametar funkcija. Ali to bi iskomplikovalo postojeci kod i usporilo rad metode koja se cesto koristi, a zarad pokrivanja slucaja koji se redje koristi, a po meni je to losa ideja...

doduse poceo sam da razmisljam ozbiljno da prepevam te phplib klase da podrze i rad sa AdoDB metodama, cisto ako zatreba ponekad... posto priznajem ja da nisu visoko apstraktni pristupi losi za neke situacije...

Znaš, meni je jedan od osnovnih principa da koristim ono što mi treba, retko radim više od potrebnog, a pisati klase za rad sa Oracle, ODBC, mssql... i čega god možeš da se setiš je po meni jednostavno gubljenje energije i vremena. Naravno, do trenutka kada ti zatreba. A tada, napišeš jednom i imaš zauvek.

Neki imaju princip da koriste "sve gotovo", znači gotove klase za sve živo, skinute sa neta. Ja sam takođe protiv toga iz najmanje 3 razloga:

1. Ne znaš ni ko je pisao ni šta je pisao, par puta sam se opekao kada sam koristio neki tuđi script koji mi je napravio haos.

2. Unutra ima mnogo koda koji ti nije ni potreban

3. Vreme koje utrošiš da se upoznaš sa "novim" sistemom možeš da iskoristiš da napišeš sam ono šta ti treba, na način koji ti treba i tačno onoliko koliko ti treba.

Ja uglavnom sednem pa napisem svoje, bas iz tog razloga sto me mrzi da raspetljavam neciji kod da bih ga razumeo. Ponekad mi se desi da koristim tudji kod bas kao crnu kutiju - ne marim kako nesto radi, bitno je da radi - a iz prostog razloga sto verujem da je kod koji je prosao kroz dosta iteracija i verzija. U boljem slucaju taj kod nije namenjen za neki kompleksan posao, verovatno je dovoljno stabilan i dobro napisan da nema potrebe da izmisljam toplu vodu po milioniti put. Ovo posebno vazi kada mi treba recimo klasa za neki smor posao (tipa crtanje raznih fancy grafikona), i ako vidim da klasa moze da odradi taj posao onako kako mi odgovara - koristicu je, osim u slucaju da mi se ceo posao vrti oko te klase, kada cu se upustiti u analizu iste i eventualno napisati novu, cistiju a mozda i funkcionalniju verziju.

Nije offtopic nego je to prica: sta koristite i zasto.

Ako sam nesto propustio - pokazite mi gde :)

Sad ćete mi još reći da je mana što recimo PDO ili ADOdb imaju poršku za toliki broj platformi? Neko jednostavno seo, napisao i dao drugima na korišćenje. Zašto moraš da izmišljaš rupu u saksiji iznova i iznova?

To što neka biblioteka ima podršku za veliki broj platformi znači par stvari:

1. Dizajnirana je tako da može da bude specijalizovana na taj način. Sam Factory pattern nije težak za napraviti i ne donosi nikakav značajan pad pad performansi.
2. Dobro i jasno definisan API. Bez toga ovi sistemi ne bi bili mogući ili bi bili jako loši.
3. Dosta ljudi je umešano u razvoj i testiranje tako da je stabilnost datog koda daleko veća nego što bi ti sam mogao da postigneš.
4. Portabilnosti
5. Smanjenje količine koda koju ti sam treba da napišeš, free

Konkretno, svaki od abs layera možeš terati u minimal modu, tj. samo sa podrškom za platformu koja ti treba. Iako dolazi sa malim milionom zapakovanih fajlova, ADOdb zahteva nekih 5 fajlova u minimalnoj instalaciji da bi radio kako treba. U manualu piše šta je sve potrebno za šta i savet kako možeš okresati instalaciju.

Mana je složeniji kod sa padom performansi, ali uz napomenu da ovo u velikom broju slučajeva ne predstavlja problem. Uostalom, zašto koristite PHP? Možete sesti, smisliti rupu u saksiji i svoju novu maestralnu web aplikaciju napisati u C-u ;)

Upravo i koristimo ove alate da bi mi manje pisali..

U čemu je fazon da ja sad treba da pišem za svaku od 50 tabela u bazi podataka - da za svaku treba da pišem INSERT, DELETE, SELECT i UPDATE izraze? Koliko je to cimanja, ako se zna da pola od tih tabela ima 30+ polja?

Što je najgore to je dosadno do zla boga. Ma idi bre :)

Jednom kad probaš neke alate iz te kategorije, povratka nazad nema.

JOINs? Šta sa njima, tačno? Definiše se potrebni VIEW u bazi, a onda opet dobijemo klasu da pozovemo ovaj pogled.

Što se kvaliteta tuđih alata tiče, zavisi šta se koristi. Neka rešenja su proverena do bola i pouzdano rade u svim situacijama.

Performanse? Nisam siguran da ima problema, ima li ko kakav test?


Nego Gorane, da vidimo konkretno.

1. Imaš tabelu sa 40 polja.
2. Imaš jednu stranicu na kojoj korisnik unosi podatke za polja te tabele
3. Imaš drugu stranicu gde trebaš da prihvatiš unete podatke i spremiš u bazu

Kako ti to radiš?

Sta je bolje, imati 200 specificnosti isprogramiranih koje kude po kodu aplikacije (a verovatno i ponavljanih) ili imati te iste specificnosti isprogramirane kroz jednu klasu (ili grupu wraper funkcija). Posao programiranja je manje vise isti, u jednom slucaju programiras na licu mesta, gde se zadesi potreba, a u drugom to isto programiras, ali na uredjen nacin, koji ti omogucuje da na neki nacin stvar organizujes, uvidis mogucnosti uopstavanja i najcesce da isti kod upotrebis na vise mesta. Nema tu viska koda koji gura prasinu. To je isti kod, samo drugacije organizovan i iskoriscen manje ili vise efikasno.

Fleksibilnost i kompromisi su uvek bili tajna uspeha. Meni se cini da treba iskoristiti prednosti svakog pristupa i apstrakciju uraditi na bar dva nivoa.

Prvi je onaj koji si ti prikazao u primeru: klasa koja obavlja sve one standardizovane procedure nad tabelema i podacima. Bilo bi idealno kada bi toj klasi mogao da "nacrtam" model baze a da mi ona obezbedi sve potrebne mehanizme pocev od kreiranja same baze pa do standardnih funkcija.

Drugi nivo su klase koje nasledjuju osnovnu klasu u prosiruju je specificnostima potrebnim za konkretnu namenu. One bi po pravilu sadrzavale rucno pisan kod.

Tako imas mogucnost da radis onako kako ti u trenutku odgovara, mozes da uopstavas, ako mislis da je potrebno, a i ne moras jer imas prostora da za specifican problem napises i specifican kod.

Ono sto ces sigurno dobiti to je citkiji kod, koji je lako pratiti i odrzavati.

Taman posla, dobro je to i lepo, ali biblioteke prosto ne mogu da pokriju sve i uvek postoji potreba da se napis eneki custom kod. Tog momenta portabilnost pada u vodu, jer ja uopste necu da se smaram sa tim da pisem kod koji ce da radi na 16 baza, od kojih samo dve-tri poznajem dovoljno da bih eventualno mogao da razmisljam o podrsci za njih.

Joj, nemoj mi stajati na zulj. Upravo tako nesto radim, pravim novi jezik koji ima istu funkciju kao i PHP. Razlika je samo sto je drugi jezik. U stvari i ne zalim se, prilicno je interesantno, kao da sam prosao kroz ogledalo pa sad ceo problem vidim "s one strane".

1)
To što alati podržavaju 20 baza, ne znači da ćeš ti u svojoj aplikaciji obavezno da koristiš kod koji može da radi sa 20 baza podataka. Ti ćeš od tih 20 podržanih baza da odabereš jednu i dobiješ klase specifične za tu bazu (i tvoje tabele).

2)
Uostalom kakvo smaranje sa pisanjem koda za 16 baza, sve i da imaš potrebu da radiš sa 16 baza? Ko to radi tako? Gde?

Programira se "against interface", tako da te uopšte nije briga koje klase se koriste. Bitno je da sve te klase podržavaju isti interfejs tako da onda za tebe nema razlike da li u pozadini koristiš klasu koja radi specifično sa Oracle 9i ili MySQL 5. U pitanju je Factory design pattern.

Možda i grešim ako si pričao samo za PHP - možda tamo moraš da se smaraš sa pisanjem različitog koda za svaku bazu. Ne znam za PHP, ali znam gde ne mora tako.

opet se vracamo na istu pricu, upotreba vise baza....ako ces uvek koristiti istu bazu, onda ce i interfejs koji koristis da bude uvek isti sve da koristis i obicne drajvere za bazu direktno.

Znaci ajde za sekund da pretpostavimo da imam mysql i da nikad necu koristiti nista drugo. Ako zanemarimo apstrakciju baze koje su onda prednosti upotrebe abst. layera ?

Degojs rece kako oni skracuju vreme kad imas dosta tabela, pa za svaku treba da se pišu INSERT, DELETE, SELECT i UPDATE i kako je to cimanje bez apstrakcije?

E sad meni nije jasno (mislim zaista ne znam, pa pitam) kako i koliko ti automatski generisane klase pomazu u tom slucaju? Koliko moze jedna automatski generisana DB abstraction klasa da ti ustedi truda?

Iz primera imam utisak da ti i dalje moras da znas koji objekat da instanciras (za svaku tabelu ima jedna klasa ako sam dobro shvatio?), a i onda da pozoves odredjenu metodu i kazes joj sta i sa kojim poljima da uradi. Meni se to cini kao drugaciji vid zapisivanja istih stvari koje bi radio iz SQL-a, i cini mi se da to moras da uradis za svaku tabelu, i za svaku akciju nad njom, bas kao i sa SQL-om, right?

u cemu je onda usteda? Ajd pls. dajte neki primer, jer ne kapiram...


A nije bas svejedno kolika je klasa koju koristis, jer na primer AdoDB ima footprint od 700KB sto nije bas malo, pogotovo ako ti skripta samo radi jedan select * from tabela

Samo da ukratko razjasnim o cemu ja tacno pricam, posto je na temi bilo reci o vise stvari.

Sto se mene tice: ja nisam jos imao priliku da radim nesto gde se menja baza (imao sam i imam priliku da radim sa vise baza na jednom sistemu; nebitno za ono sto sam imao na umu). Ima nagovestaja da cu uskoro prvi put i to da radim, ali o tom kad se desi :)

Dalje, ja ne pricam o alatima za mapiranje objekata u relacionu bazu. Nisam to nikad radio te i to preskacem.

E ono sto JESAM radio jeste otprilike ovako: nove tabele u bazi - oko 50 tabela, pola od njih ima 30+ polja.

Da, ako sam dobro razumeo. Za svaku tabelu/pogled imas jednu klasu.

Pazi sad, da ja dobijem mogucnost da iz aplikacije radim UPDATE/INSERT/DELETE/SELECT svake od tabela (kao i komplikovaniji SELECT) meni je potrebno, jednom kad su tabele (i pogledi, ako treba) u bazi gotove, tacno nekih 30 sekundi dok program generise te klase. I gotova prica.

Koliko je tebi vremena potrebno da za svaku tabelu imas istu funkcionalnost? Da je kod konzistentan, cist, pregledan i DOBRO testiran?

Ej bre, znas li koliko tu ima fizikalisanja?? I onda jos gledaj da nisi neko polje preskocio..? Zato i pitam: kako bi ti to uradio, koliko vremena bi ti trebalo?

Kad ovo odgovoris, idemo dalje, nije tu kraj price: zato sam i pitao Gorana kako bi on uradio onaj slucaj koji sam opisao. Sve sa malo koda, jer mi se cini da vi olako preskacete neke detalje koji, bar mene, smaraju do zla boga.

uf, meni i dalje nije najasnija razlika, ali ajde bolje da krenemo sa malo primera koda, tako ce biti jasnije...so I'll show you mine and then you show me yours :)

Sa bibliotekom koju trenutno koristim, a koja je vrlo slicna phpLib postupak je otprilike:

$db->query('neki_sql');

gde je 'neki_sql' INSERT, UPDATE, ALTER TABLE ili koji god sql query mi treba... Ako radim SELECT onda bi jos trebalo da pokupim rezultate sa :
while ( $db->fetch_next()) { ... }
ili sa
$a = $db->fetch_all();

Sama klasa brine o tome da se (na osnovu podatak iz config fajla ili direktno propertija nasledjene klase) poveze na bazu (ako vec nije povezana), da uhvati greske(poziva registrovanu callback funkciju), da oslobodi resurse kad nisu potrebni, a postoji i varijanta query metode u kojoj radi escape promenjivih:

$sql = "SELECT * FROM nesto WHERE id=? AND ime='?' ";
$db->query($sql, 1, 'pera');

ovo je moj dodatak koji naprosto uradi escape parametara i zameni ih umesto ? u sql upitu (nije pravi sql prepare, jer php drajveri ne podrzavaju to...)

sa $db->num_rows ili $db->affected_rows moze da se proveri koliko je rezultata, odnosno promena izvrseno...

I onda tako za svaku potrebnu operaciju nad svakom tabelom... koliko ce ovo biti citljivo zavisi naravno od komplikovanosti SQL upita (na webu obicno nisu preterano komplikovani), a i od toga koliko onaj ko cita zna SQL :)

Ajd sad please daj da vidim kontra primer, kako ovo uraditi jednostavnije... ja i trazim nacin da ustedim vreme, zato sam i zapoceo celu pricu...

Nemoj ti meni najjednostavniji primer sa SELECT * WHERE a=b AND c=d, nego daj lepo da vidim primer za INSERT i UPDATE u tabelu gde imamo 30 polja. Ja uporno ponavljam "veci broj tabela, tabele sa vise polja" a ti meni "Evo ti SELECT *" gde prakticno nije ni bitno koliko polja ima :)

Hajde lepo, tabela ima 30 polja. Da vidimo INSERT, da vidimo UPDATE. Pa onda to ponovi 25 puta, za 25 raznih tabela. Hajde da vidimo da li je smaranje ili nije.

1. na prvoj stranici ima recimo 30 polja u koje korisnik unosi neke tamo leve podatke
i tako recimo 30 komada, mozda neki <select> i sta vec treba.

Kako kod tebe izgleda druga stranica koja ce da prihvati podatke i doda novi zapis u tabeli u bazi?

Kod mene, evo kako bi to izgledalo u Javi, ovo je citava stranica:
A da sam trebao update samo bi bilo:

boolean OK = customerDataForm.update();


Pazi bre, ja niti sam klase kreirao, niti sam pisao SQL. I tako moze za svaku tabelu. Samo sam napravio tabele u bazi.

Ako moze i kod tebe ovo isto, a drugacije, pricaj :) Meni je ovo bre usteda i vremena i zivaca.

Raspisali ste se, ja kao sve "kasnije ću na miru da pročitam", a ono sve više. Dakle:

Ako tabela ima 40 polja, onda nešto nije u redu sa tom bazom, fali joj malo sređivanja :) Ili radiš sajt za neku kladionicu :) Pa čak i ako ima, koliko ima takvih tabela? 1 u 10 godina? No dobro...

Ja sam napravio svoju klasu koja ne samo da radi te poslove tipa INSERT, UPDATE automatski nego generiše formulare, generiše server I client side error control (client: javascript, pre submit).

Znači korisnik klikne na submit, ja u kodu imam nešto ovako:
ili getUpdateQuery ();
ili getDeleteQuery ();

i onda izvrsim query koji je u stringu - posaljem ga DB klasi.

Znači, ovo je odgovor na "kako ti to radiš", ali mislim da namerno skrećeš sa teme. Niko ovde (odnosno, bar ne ja) ne priča o ovakvim query-jima. Ja govorim recimo o situaciji:
Koji "automatizam" moze da ti generise ovakav query ? Verovatno moze, ali moras da se ubijes i da potrosis gomilu vremena da izdefinises relacije, views... kako god ih zoves.

Pored toga, vecina stvari se cesto ponavlja, tako da recimo ako jednom napravis klasu users gde se on loguje, menja podatke, pretrazuje usere... onda je posao oko novog sajta samo da prekopiras klasu koju imas i eventualno dodas ili oduzmes par polja koja su specificna za odredjeni sajt.

I kažeš cimanje pisati sve te INSERT, UPDATE... Slažem se da je dosadno, ali veće je cimanje definisati tabele kao neki XML ili šta god, pa onda definisati relacije, pa views, pa ovo-ono (pri tom, uvek dođe do neke izmene kasnije pa moraš da predefinišeš relacije pa sve ponovo), pa onda to provaličit kroz neki kod koji će da generiše drugi kod koji bi trebao da radi sa nečim trećim... Koja je tu ušteda u vremenu ili trudu? A pokrenuo si ne samo artiljeriju nego i strateške bombardere i nuklearni arsenal da nebi pisao par querija koje si mogao da napišeš za kreće vreme nego što si napisao postove na ovoj temi.

I non sto pričate o portabilnosti. Nice. Ali, WTF? Koliko puta si morao da portuješ nešto na drugu platformu? Once in a lifetime? Hajde da čujemo koliko ljudi je portovalo nešto na drugu platformu gde mu se isplatio portabilan kod? Možda par? Možda ni jedan.

Je l' da?

Jesi radio nekad aplikaciju koja radi sa pacijentima, bolestima, nalazima, simptomima, tretmanima, epidemijama i slično?

Forme na kojima radimo dobivamo direktno iz prakse. Otkud znam, možda bezveze popunjavaju formulare i slično. Eh sad.. možda smo i mi i oni ludi, a možda ti ne znaš tačno šta i kako to izgleda..

Čak smo i, naravno, forme gde je god bilo moguće "obrnuli" u tabelama tako da se dinamički generišu iz redova u tabeli, a ne kolona.

Eh.

Pa jebi ga, ti napravio svoju klasu, a ja koristim nečiju aplikaciju koja radi to isto :)

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