Forum PHP.pl

Nie raz spotkalem sie juz z pojeciem DAO: Data Access Object. Czym to jest? Do czego słuzy? Czy jest to kontroler bazy danych jak np. AdoDB? To jest wzorzec projektowy? narazie moja wiedza na temat tego jest zerowa - pelna domyslow i niedomowien.

OMFG: http://www.google.com/search?hl=en&hs=xgr&...ss+data&spell=1

juz lepiej?

Po chłopsku ADO - to adapter baz danych - umożliwia przynajmniej w teorii stowrzenie zapytań sqlowych, które zostaną poprawnie zinterpretowane przez wszystkie obsługiwane przez dany adapter bazy. Przejście na inną bazę wiąże się zaledwie z kilkoma zamianami w zakresie konfiguracji adaptera.

DAO to odmienne podejscie do tego samego problemu. Tu nie tworzy się kodu uniwersalnego, ale wręcz przeciwnie - kod wyspecjalizowany pod katem wybranej bazy. Obiekt DAO zawiera tę część kodu, która - w przypadku podjęcia decyzji o dostosowaniu aplikacji do innej bazy danych - musi zostać sprawdzona co do zgodności z nową bazą. Z reguły pisze się po prostu osobną klasę DAO dla każdego serwera baz danych. Podejście to wymaga więcej pracy niż ADO, ale za to kod jest zoptymalizowany, a aplikacja bardziej wydajna.

przy okazji. php5 posiada PDO czyli php Database Object. Wszystko jest super jesli nie chodzi o mysql. Posiada on dosc denerwojacego bug'a ktorzy poprostu killuje skrypt.

PDO - pomijajac bugi - dostrcza jedynie wspolny interfejs przy obsludze baz danych, ale nie umozliwia bynajmniej pisanie uniwersalnego kodu. PDO nie jest abstrakcja baz danych na miarę AdoDB, ale juz na pszyklad Zend_Db korzystajacy z PDO sie do tego zbliza. Niestety Zend_Db ma wciaż wiele bledow, ktore poniekad wynikaja z niedoskonalosci PDO. Warto tez wspomniec, ze mozna tez posluzyc sie Zend_Db jednoczesnie niekorzystajac z PDO, ale jak narazie tylko w przypadku MySQLa i Oracla.

Ten post edytował bigZbig 1.07.2006, 09:53:28

Sh4dow: Jaki bug? Skoro masz ważne informacje to się podziel

Co do bugów PDO... też mam z jednym doczynienia. Tzn ciągle nie wiem czy to jego sprawka, ale problem jest dziwny:
http://blog.stanowski.info/2006/06/08/problem-z-ormpdo/

jesli chodzi o PDO to blad jest typowo po stronie servera. Biblioteka PDO_mysql ubija dzicko apache. Niestety nie wiem czy to wina samego PDO czy biblioteki mysql z ktora sie komunikuje. Nie jestem odosobnionym przypadkiem. przy tym bugu bylo juz parenascie komentarzy z powtarzajacym sie bledem. PDO dziala, ale nagle powoduje crash na clej lini. Nie jest to wina samego zapytania, bo po wykonaniu tego zapytania w innym miejscu to dziala. Naprzyklad u mnie bylo to 3 zapytanie przy ktorym "umierał".
W innych przypadkach bylo to naprzykład 4 zapytania. Wiem ze nad bugiem pracuja bo byly poprawki ale nie zawsze dzialaly.

Co do PDO ze nie jest idealne zgodze sie, ale przeciez jako programisci mozemy sobie ułatwic to i oprogramowac to wszystko i działa cudnie. Jeśli bug zostanie zlikwidowany postaram sie napisac tutaj.

PDO ma błąd związany z czyszczeniem własnych śmieci. Bardzo często wywołanie funkcji die/exit po zapytaniu poprzez PDO powoduje błąd 500.

http://bugs.php.net/bug.php?id=38095
http://bugs.php.net/bug.php?id=37445

Odświeże lekko
http://bugs.php.net/bug.php?id=37445
Został poprawiony w becie 5.2.


Koniec offa z mojej strony ;D

Pozdrawiam (;

Odnosnie ADO to do bardzo skomplikowanych zapytan dla wielu baz jednoczesnie nie da sie uzyc. W niektorych bazach pewne funkcjonalnosci sa nie zaimplementowane. Najczesciej w projektach spotyka sie rozwiazania ADO, gdzie i tak projekt jest skazany wylacznie tylko na jedna baze danych.

Odnosnie bledow PDO ma jeszcze jeden powazny blad zwiazany ze zwracaniem: Temat: PDO Bind i wysypka PHPa

Uzycie ADO ma sens jedynie w przypadku uzycia maksymalnie prostych zapytan, a w takim wypadku jest to zawsze kompromis pomiedzy elastycznaoscia a wydajnoscia. Jesli chcesz zoptymalizowac swoj skrypt pod katem wydajnosci musisz niestety zrezygnowac z rozwiazan uniwersalnych typu ADO czy ORM.

W większości przypadków można użyć widoków lub procedur składowanych. Pozatym ręczne składanie bardzo rozbudowanych zapytań SQL jest niewskazane z uwagi na trudności z modyfikacją.

I to w przypadku ORM jest trudnoscia, wiem to z doswiadczenia. Problem jest: 1 z wydajnoscia bo widok musi gotowe zbiory danych zwracac i zapytanie robisz do niego, 2 to nie zawsze tak latwo jest warunkami manewrowac. Wszystko zalezy od stopnia skomplikowania bazy i wyciaganych danych.

ORM ma jedna wade (teoretycznie takie narzedzie jak explain plan idzie w odstawke)