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?

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.

A może Propel?

Ja myślę, że wystarczy API, na tyle spójne aby obsługiwało kilka baz (MySQL, PostgerSQL, MSSQL, itp). Zwykle DB Layer składa się z niskopoziomowych funkcji. Można stworzyć klasę funkcji wysokopoziomowych jako dodatek. To jest moje zdanie.

@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?

@hawk -> dlatego aby współnym AIP obsłużyć MySQL, SQLite etc..

@Nievinny: powtarzam, jaki jest sens tworzyć wspólne API do obsługi MySQL, SQLite etc., skoro php ma wbudowane wspólne API do obsługi MySQL, SQLite, etc.?

Dla niewtajemniczonych: PDO. I w zasadzie to wbudowane ono dopiero będzie, na razie chyba trzeba sobie dociągnąć. Co nie zmienia faktu że będzie.

@hawk: najpierw mial to byc prosty layerek, ale wzrpsly wymagania wbec niego i zaczalem wywazac otwarte drzwi. Dzieki za przypomnienie i linki (zaoszczedziles mi troche roboty .
Dobry pomysl z tym PDO (na razei jako PECL a od 5.1 w php).

Biore sie za sprawdzanie Creola.

@hawk -> OK, ale czemu nie stworzyć własnego z dodatkowymi funkcjami, np Cache, lub zliczanie zapytań?

@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?

@hawk -> Czyli twoim zdaniem należy wykorzystać PDO i dodać do tego Cache?
Ale, PDO nie ma w PHP4, a ładowanie rozszerzeń za pomocą dl() to przesada, więc jak to zrobić w PHP4?

Przesiasc sie na 5ke.

@dr_bonzo -> ja działam na PHP5, ale nie każdy zleceniodawca ma tę 5, więc nie da się inaczej. A poprosiłbym jeszcze o jakieś przykłady wykorzystania PDO?

A czytales cokolwiek o PDO?
Mozesz z nim zrobic to samo co ze standardowymi rozszerzeniami (mysql, psql, ...) tylko dla kazdego uzywasz tych samych metod (wspolne API) niezaleznie od bazy danych.

@dr_bonzo Co do pierwszego rozwiazania to troche bedzie problem niby SQL to standard ale w roznych bazach rozne sie zapisuje, np limit - w ORACLE takie cos nie istnieje.

@dr_bonzo -> czytałem i chodzi mi oto, że jakiś ksrypcik przykładowo... A pozatym jak admin serwera nie udostępni tych rozszerzeń? To co? Myślę, że dopuki nie będzie na standardzie to nie ma szans na skuteczne użycie zawsze i wszędzie...

@Nievinny: jak admin serwera nie udostępni rozszerzenia do <tu wstaw swoją bazę danych> to i tak nic nie będzie działać.

No dobra, skoro działasz na PHP4, to czemu nie chcesz używać ADODB? Trochę się czepiam, nie chodzi mi akurat o ciebie ani o to samo ADODB. Chodzi mi o to, że jest dla php wiele gotowych rozwiązań. Jedne już wchodzące jako standard (PDO), inne powszechnie używane. I co? I nic. Napiszmy wszystko od nowa.

BTW, pomijając różnice pomiędzy PHP4 a 5, PDO nie jest rozszerzeniem, które może być lub nie być. Od PHP5.1 sprawa ma być prosta: masz obsługę np. MySQL = automatycznie masz PDO dla MySQL.

BTW2, jak ktoś interesuje się PDO, to niech poszuka też o DBDO. Świat php nie jest jednomyślny, ale to są już dyskusje na znacznie wyższym poziomie merytorycznym.

@hawk -> działam na 4 tylko kiedy zlecą mi wykonanie skryptu pod 4. Zwykle działam pod 5. I używam co prawda nie ADoDB, ale innego dobrego db layera. I chętnie zacznę używać gotowego PDO, tylko wskażcie mi, że admin servera na którym jest php powiedzmy 5.0.3 (lub inne z serii 5.0.x) udostępni rozszerzenie PDO dla skryptów to będe to wykorzystywał. Inaczej muszę używać mysql_cos lub sqlite_cos

Hm, a ja mam do Was pytanie. Chcąc pisać skrypty, w miarę niezależne od typów baz, jednocześnie nie komplikując ich kodu, jak byście rowiązali problem dot. zwracania przez dany model, tych samych danych, ale przy różnych (w treści) zapytaniach.
Czy wyralibyście:

A) tworzymy globalną tablicę typu:

[PHP] pobierz, plaintext 
<?
$arrQueries['mysql']['select user'] = 'SELECT * FROM...';
$arrQueries['pgsql']['select user'] = 'SELECT * FROM...';
$arrQueries['sqlite']['select user'] = 'SELECT * FROM...';
?>
[PHP] pobierz, plaintext 

Potem, odwołując się odpowiednio do tej tablicy:

[PHP] pobierz, plaintext 
<? $resResult = $db->query($arrQueries[DB_TYPE]['select user']);?>
[PHP] pobierz, plaintext 

B) Tworzymy oddzielne modele i sterownik bazy dla każdej z baz.
C) Tworzymy jeden model, ale w każdej metodzie występuje switch.

[PHP] pobierz, plaintext 
<?
switch(DB_TYPE)
{
case 'mysql': $q='SELECT * FROM...'; break;
case 'pgsql': $q='SELECT * FROM...'; break;
case 'sqlite': $q='SELECT * FROM...'; break;
}
$resResult = $db->query($q);
?>
[PHP] pobierz, plaintext 

D) Przygotowujemy oddzielne skrypty. z odpowiednią obsługą - najprostrze,ale najbardziej czasochłonne przy modyfikacjach.

Szczerze mówiąc, wybrał bym wariant B. Co o tym myślicie?

e) Kozystamy z gotowego rozwiazania: ezsql, adodb, creole.
Btw: przyklady troche bez sensu, bo we wszystkich tych bazach zapytania maja niemal identyczna strukture (selecty we wszystkich), wiec po co do kazdej bazy dawac inne zapytanie (ktore de facto bedzie identyczne?

Tam był przykład... Poza tym nie wkażdej bazie JOIN'ty, grupowanie,sortowanie wyglada tak samo.

Dlatego wg. mnie abstrakcja bazy danych powinna zajmować się jedynie łączeniem z bazą + wysyłaniem zapytań i zwracaniem wyniku.
A nie dopieraniem zapytania automatycznie do wybranej bazy.
Tak jak to robią AdoDB np. w sprawie limitowania.

Ja robie tak, że dla każdej bazy jak i każdego "innego niż mysql" sposoby przetrzymywania danych mam różne klasy(modele) o wspólnym interfejsie. Dokładnie jak w MVC.