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?

[hawk]

@dr_bonzo: A po co ty to w ogóle piszesz? Pisanie takiej biblioteki ma sens wtedy, gdy ma ona być lepsza (przynajmniej w czymś) od istniejących. A jest tego sporo, począwszy od prostych API, skończywszy na ORM. PEAR DB, ADODB, PDO, EZPDO, Creole, MetaStorage, Entity, Propel, DB_DataObject... większości nie znam, więc nie będę oceniał. Czym twoja biblioteka będzie się wyróżniać?

@rzseattle: większość z tego, co wymieniłem, to chyba właśnie ORM. Możesz obejrzeć dokumentację, ja się niestety nie znam na temacie.

@Nievinny: jaki jest sens pisania własnego, spójnego API, skoro php ma takie API wbudowane?