db layer, jak pisac? Opcje

[dr_bonzo]

Stoje przed zadaniem napisania abstrakcji na bazy danych i mam dwa rozwiazania do wyboru:

1. zupelna abstrakcja od api az po pseudo skladnie sql, ktora ma byc identyczna dla kazdej z baz (lub zamiast skladni, budowanie zapytania, np.
$q = $db->newQuyery( 'select' );
$q->addFields( array( 'ID', 'blabla' ) );
$q->addTable(...
$q->limited( 3,5 );
subqueries
triggers
transactions
itd...
masa roboty, ale za to mam calkowita niezaleznosc od bazy, nie moge wykorzystac wszystkich mozliwosci bazy (np. triggery w psql -- w mysqlu chyba nie ma?)

[aplikacja]<->[db layer]<-**[DB]

lub

2. tworze tylko wspolne api -- sql bedzie recznie wpisywany i bedzie rozny dla roznych baz + tworze kolejna abstrakcje (dla kazdej z baz) zawierajaca podstawowe zapytanie uzywane przez aplikacje, np. pobierz dane usera, pobierz wszystkie newsy

[aplikacja]<->[podstawowe operacje]<-**[db layer (bardziej API)]<->[DB]

co jest latwiejsze (chyba) do napisania ale nie mam calkowitej niezaleznosci od bazy i przenoszenie na inna baze wymaga napisania nowych "podstawowych funkcji".

Jak wy to rozwiazaliscie, ktore z rozwiazan sie sprawdza? A moze macie inne pomysly?

[rzseattle]

Problem ktory poruszyles jest dosc zlozony. Mozna do niego podejsc na roznorakie sposoby. Ja proponuje ci calkowicie uniezaleznienie sie od SQL i potraktowanie tabeli jako obiektu.

Nie bede na ten temat sie rozpisywal. http://rzseattle.piwko.pl/doObject/ tutaj znajdziesz stara dokumentacje do mojego obiektu obslugujacego baze danych. Dokumentacja obejmuje niezbedna podstawe do tego co ci jest potrzebne. Niestety obecnie dokumentacja nie nadaza za kodem wiec nie ma w niej opisanych bardziej zaawansowanych rzeczy.

Jesli ktos ma podobne dokumentacje to chetnie je obejze.