DevProTalk - DB Abstraction Layer, koji koristite ?

DevProTalk (http://www.devprotalk.com/index.php)

- SQL baze podataka - Sponzor: Baze-Podataka.net (http://www.devprotalk.com/forumdisplay.php?f=10)

- - DB Abstraction Layer, koji koristite ? (http://www.devprotalk.com/showthread.php?t=573)

Off Topic: E bas je dobar ovaj DBDesigner4, nisam ga do sad nikad koristio..

a jel ima on neku caku da se polju u tabeli dodeli komentar (da ne jurim po helpu)

U verziji koju korsitim jedno od polja koja mozes da popunis prilikom definisanja polja tabele je i komentar.

evo jedne zanimljive (bar meni) price na ovu temu na koju sam slucajno naleteo trazeci nesto peto na sitepointu (da ne ispadne da sam opsednut bazama :P ):

http://www.sitepoint.com/forums/prin...t=82885&pp=200

Ajoj, al je taj što je to pisao blesav..

Citat:

So if I use database abstracion and write my application for MySQL and then later want to switch to PostgreSQL or Oracle, although I won't have to change most of the method calls in my scripts, I will still have to change almost all of the SQL queries!

Priča o apstrakciji a onda kaže da će da menja SQL kverije. Pa kakvi SQL upiti ako koristiš upravo apstrakciju? Pa on ne razume uopšte ni pola priče.. Koja glupost. Pa ti sistemu treba da kažeš koju bazu koristiš da bi on mogao da koristi kod specifičan za tu bazu, a ne.. da abstraction layer nekom magijom ima SQL kod koji radi na svim bazama. Svašta. Već sam napisao pre, može da se koristi Factory dp.

Dalje nisam ni čitao.

Trebao si jos malo da citas :) Ono o cemu covek pise ima dosta rezona a mi bas pomenusmo ovde Delphi jer je to njegov rezon i pokazao se veoma mocan i praktican.

Evo cemu se radi, napravis osnovnu klasu koja obezbedjuje uopstene mehanizme za rad sa bazom od kojih su vecina smao definisani ali ne i implementirani.

Onda pravis klasu koja radi sa odredjenom bazom tako sto nasledis osnovnu klasu, obezbedis funkcionalnost za definisane metode a mozes da je prosiris i svojim.

Mozes da napravis i klasu za neku drugu bazu na isti nacin, tako sto nasledis osnovnu, das joj funcionalnost i prosiris je.

Neko sasvim treci, moze da napravi klasu za neku sasvim trecu bazu tako sto ce narpaviti novukalsu nasledjujuci osnovnu.

Osnovna prenost je sto su sve te klase medjusobno kompatibilne, a promena podrzane baze se moze svesti na to da umesto jedne, koristis drugu klasu. naranvo, i dalej ostaje ogranicenje custom SQL upita, koji se ni na koji nacin ne mogu tek tako biti automatski portovani na drugu bazu.

Citat:

Originalno napisao degojs

Ajoj, al je taj što je to pisao blesav..

Priča o apstrakciji a onda kaže da će da menja SQL kverije. Pa kakvi SQL upiti ako koristiš upravo apstrakciju? Pa on ne razume uopšte ni pola priče.. Koja glupost. Pa ti sistemu treba da kažeš koju bazu koristiš da bi on mogao da koristi kod specifičan za tu bazu, a ne.. da abstraction layer nekom magijom ima SQL kod koji radi na svim bazama. Svašta. Već sam napisao pre, može da se koristi Factory dp.

Dalje nisam ni čitao.

Covek prica o Pear: DB i AdoDB, najpopularnijim abstraction layerima za PHP, i u jednom i u drugom se pisu SQL queriji direktno... tako da ne prica on gluposti nego ti ne znas kako se to radi u php-u...

Da si procitao ceo text video bi da se prica o ideji da je (po njemu) pogresno bazu asptrakovati tabelu po tabelu, ili query po query, nego treba apstrakcija da bude zasnovana na prirodi entiteta sa kojim radis, tipa imas recimo klasu User i sve sa njom radis, a ne zanima te da li userove podatke cuvas u jednoj ili 5 tabela, to je pitanje implementacije same klase i zavisi, izmedju ostalog i od tipa baze...

to je u stvari ista fora kao da imas View u bazi koji ti joinuje sve podatke za Usera, pa sa njim radis...tebe ne zanima odakle ti podaci dolaze u View, samo te interesuje koje se polje kako zove....

Postoji velika razlika između apstrakcije pristupa bazi i apstrakcije pristupa podacima. Ljudi kada govore o apstrakcionim slojevima (PHP svet) obično misle na ovo prvo, a trebalo bi da misle na ovo drugo.

PHP kôd:


		
			
$conn = get_connection('mysql');

if(!$conn->connect('localhost', 'root', '', 'test')) die('Ups!');

$result = $conn->execute('SELECT * FROM `products`');

Primer sam lupio iz glave, ali ovo je nešto što većina PHP developera smatra apstrakcijom (i što degojsu izgleda non stop promiče). To je daleko od prave apstrakcije. Samo je defininisan API za komunikaciju sa više različitih baza i par pomoćnih metoda (izvuci sve podatke iz rezultata kao niz nizova i sl).

Prava apstrakcija bi bilo nešto slično ovome:

PHP kôd:


		
			
$user = new User();

$user->setUsername('root');

$user->setPassword('***');

$user->setEmail('mail@somebody.com');

try {

  $user->save();

} catch(Exception $e) {

  die($e->getMessage());

}

Da li ja znam šta će se desiti? Znam: novi korisnik će biti kreiran sa zadatim podacima. Da li znam gde će i kako podaci biti sačuvani? Ne nužno... To može biti baza, može biti fajl, može biti poslat zahtev nekoj drugoj aplikaciji na drugom računaru da doda korisnika... Uostalom, ne zanima me. Ako nešto pođe na loše biću obavešten o tome.

OK, dodato. Šta dalje?

PHP kôd:


		
			
// Load...

$user = Users::load(12);



// Update

$user->setPassword('*******');

try {

  $user->save();

} catch(Exception $e) {

  die('Greška pri izmeni. Razlog: ' . $e->getMessage());

}



// Delete

try {

  $user->delete();

} catch(Exception $e) {

  die('Greška pri brianju. Razlog: ' . $e->getMessage());

}



die('Korisnik uspešno orbisan!');

Jednostavno se u aplikaciji ne brinemo o načinima na koji se podaci skladište već o samom baratanju njima.

PS: Ja stvarno ne razumem zašto ljudi toliko ističu prebacivanje sa jedne na durgu platformu kao osnovnu prednost apstrakcionih slojeva. Taj slučaj je toliko redak da je to nešto što bi trebalo da se nalazi negde pri dnu features liste. Skroz je OK imati tu mogućnost, ali definitivno je ne treba toliko isticati. Ono što je meni najvažnije kod njih je što te oslobađaju vodoinstalaterskog posla na relaciji aplikacija-baza i mogućnost da se u aplikaciji posvetim samom baratanju podacima.

PPS: Sva tri primera su iz glave i služe samo da ilustruju kompletnu priču kroz kod.

Verovatno zbog nepoznavanja terminologije, ja takav nacin rada nazivam "modularni pristup", bas iz razloga sto meni, recimo, sloj za interakciju sa bazom predstavlja poseban modul, koji se automatski ucitava ako ja iz nekog treceg modula pozovem modul User (jer sticajem okolnosti korisnike cuvam u mysql bazi), a koje module on koristi da bi obavio posao apsolutno me se ne tice - koristim njegove metode i tako za svaki pojedinacan modul.

Mislim da se mogucnost transparentne promene db engine-a forsira pre svega sto omogucava developerima koji koriste razlicite baze da koriste isti abstraction layer na potpuno isti nacin kao da koriste bilo koju od podrzanih baza, dakle iz razloga popularizacije istog. A to sto programer koji koristi pgsql verovatno nikad nece hteti da koristi recimo sqlite... Pa, bitno je da ima i tu mogucnost...

Citat:

Originalno napisao zextra

Mislim da se mogucnost transparentne promene db engine-a forsira pre svega sto omogucava developerima koji koriste razlicite baze da koriste isti abstraction layer na potpuno isti nacin kao da koriste bilo koju od podrzanih baza, dakle iz razloga popularizacije istog.

Slažem se, ali preterano isticanje te mogućnosti je dovelo do toga da dobar deo programera gleda na to kao njihovu jedinu svrhu...

I never said it's a Good Thing(tm) :)