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]

@Nievinny: a czemu nie stworzysz od podstaw własnego parsera XML? Własnego silnika do regexpów? Własnego <tu wstaw dowolne rozszerzenie php>... Bo php już to ma.

Dlaczego nikt w Javie nie pisze własnego JSP? Nikt nie pisze aplikacji desktopowych pisząc najpierw własną implementację Swinga?

Dlaczego wreszcie nie napisać w ogóle aplikacji w php zaczynając od reimplementacji od nowa w C samego silnika php?

A konkretnie: jeżeli warto zaimplementować mechanizm cache (pewnie warto, bo PDO AFAIK nie ma), to chyba lepiej oprzeć się o PDO, niż pisać wszystko samemu od podstaw?