Oboje mają przygotowane oświadczenia. pg_ * to wrapper do libpq. Dobrze?PDO vs pg_ * funkcje
Lubię PDO w PHP, ale ja nie zamierzam zmienić bazę danych w przyszłości. Jakiej biblioteki mam użyć? Jakieś testy porównawcze? Wersja PHP 5,4
IMHO za pomocą funkcji, która zbliża się bezpośrednio do betonu PB (jak pg_, oci_, mysql[i]_ itd.) jest zawsze nieco szybciej, a następnie za pomocą PDO lub każda warstwa DBMS (Nauki, DiBi, etc.) .
Ale korzystanie z PDO lub dowolnej warstwy DBMS w architekturze OOP powinno być lepszym podejściem (IMHO, jeszcze raz), ponieważ uczysz się korzystać z tej warstwy, a tym samym użyje jej na dowolnym silniku DB. Oczywiście, jeśli zmienisz silnik DB w aplikacji Nie musisz zawracać sobie głowy przepisywaniem całej aplikacji.
Nawet jeśli nie planujesz zmienić silnik DB Polecam korzystania z PDO. Ale to tylko moja opinia :-)
myślę, że to jest bardziej kwestia gustu. PDO może być szybszy, ponieważ jest skompilowany lub może nie być, ponieważ działa jako opakowanie. Jestem pewien, że różnica prędkości byłaby na tyle mała, aby nie wpłynąć na twoją decyzję.
Jest to czysta spekulacja, ale PDO jest nowy i wydaje się być standardem dla połączeń DB teraz, więc wsparcie dla niego pod względem kodu będzie prawdopodobnie rosnąć, natomiast wsparcie dla mysql_* i prawdopodobnie pg_* nadal będzie słabnąć.
Główną zaletą PDO jest to, że jego abstrakcja pozwoli później przejść do innego DB, ale założę się, że nie, więc prawdopodobnie nie powinno to wpłynąć na decyzję.
ja osobiście wolę pracować z PDO. Łatwiej jest przekazywać i kontrolować obiekty niż zmienne "zasób".
Eksplozja, jesteś pewien? Jestem nowy w PHP i Postgre i do tej pory muszę zdecydować, z której technologii skorzystam, przeprowadziłem testy, a pg_connect wydaje się być szybszy niż PDO. – HMarioD
PDO oferuje przyjemny interfejs, ale bardziej genericity oznacza również więcej problemów do czynienia z subtelnych dziwactw każdego zaplecza. Jeśli spojrzeć na the bugtracker, ma wiele otwartych problemów, a niektóre z nich są poważne.
Oto niepotwierdzony dowód z postgresql: parser PDO ma problem z ustawieniem standardowego standardu_konfiguracyjnego na ON (obecnie jest to domyślne, jak w przypadku PG-9.1). przypadku badania z php 5.3.9:
$dbh->exec("SET standard_conforming_strings=on");
$p=$dbh->prepare("SELECT 1 WHERE 'ab\' = :foo AND 'cd' = :bar");
$p->execute(array(":foo" => "ab", ":bar" => "cd"));
wykonania() nieoczekiwanie nie w warstwie PDO z Database error: SQLSTATE[HY093]: Invalid parameter number: :foo. Wygląda na to, że nie jest w stanie zidentyfikować: foo jako parametru.
Jeśli zapytanie zatrzymuje się po 'ab\'=:foo, bez innego warunku, to działa dobrze. Lub, jeśli drugi warunek nie zawiera ciągu, działa również dobrze.
Problem wygląda podobnie do issue #55335, który został odrzucony jako Nie jest to błąd, całkiem błędnie moim zdaniem. [Właściwie to włamałem się nawet do PDO, żeby to naprawić, ale w sposób niezgodny z innymi backendami, więc bez łatki. Byłem zirytowany, że analizator leksykalny zapytania jest tak generyczny.]
Z drugiej strony, pg_ * jest bliżej libpq, ten rodzaj problemu jest mniej prawdopodobny i łatwiejszy do rozwiązania, jeśli tak się stanie.
Więc moim celem byłoby, że nie wszystko jest dobre z ChNP. Wewnętrznie jest to z pewnością trudniejsze niż pg_ *, a większa złożoność oznacza więcej błędów. Czy te błędy zostały rozwiązane? Na podstawie pewnych wpisów w systemie bugtracker, niekoniecznie.
+1 Doskonały post. Uczyniłem twój punkt bardzo jasnym, uzasadnionym odpowiednimi dowodami. Zbliżenie się do RDBMS jest szybsze i czystsze. –
@MorrisonHotel Przepraszam? – shadyyx
Mój komentarz jest zły, nie Ty :) – MorrisonHotel
PostgreSQL: ** WYBIERZ TO_STRING (...) Z Mytable LIMIT 1 OFFSET 1 ** MySQL: ** SELECT DATE_FORMAT (...) Z Mytable LIMIT 1,1 ** Jak widzimy, nawet przy użyciu ChNP, będę musiał przepisać wszystkie żądania do bazy danych. Tak więc, PDO nie jest panaceum. Będę musiał użyć Doctrine, Propel, itp. (Jest wykluczony). – MorrisonHotel