PDO vs pg_ * funzioni

Question

Entrambi hanno dichiarazioni preparate. pg_ * è un wrapper per libpq. Destra?

Mi piace il PDO in PHP, ma non ho intenzione di cambiare il database in futuro. Quale libreria dovrei usare? Qualche punto di riferimento? Versione PHP: 5.4

Answer 1

IMHO utilizzando le funzioni che si avvicina direttamente concreto DB (come pg_, oci_, mysql[i]_ ecc) è sempre un po 'più veloce quindi utilizzando una DOP o di qualsiasi livello DBMS (Dottrina, dibi, etc.) .

Tuttavia, l'utilizzo di PDO o di qualsiasi livello DBMS nell'architettura OOP dovrebbe essere un approccio migliore (IMHO, ancora una volta), poiché si impara a utilizzare questo livello e quindi lo si utilizzerà su qualsiasi motore di database. Ovviamente se cambi il motore DB all'interno dell'app non devi preoccuparti di riscrivere l'intera app.

Anche se non si prevede di modificare il motore del database, si consiglia di utilizzare PDO. Ma questa è solo la mia opinione :-)

Answer 2

Penso che sia più una questione di gusti. PDO potrebbe essere più veloce da quando è stato compilato, o potrebbe non essere dato che funge da wrapper. Sono sicuro che la differenza di velocità sarebbe abbastanza piccola da non influire sulla tua decisione.

Questa è pura speculazione, ma PDO è nuovo e sembra essere lo standard per le connessioni DB, in modo che il supporto per esso in termini di codice probabilmente crescerà, mentre il supporto per mysql_* e probabilmente pg_* continuerà a diminuire.

Il vantaggio principale di PDO è che la sua astrazione ti permetterà di passare a un DB diverso in seguito, ma scommetto che non lo farai, quindi probabilmente non dovresti influenzare la tua decisione.

Personalmente preferisco lavorare con PDO. È più facile passare e controllare oggetti rispetto alle variabili "risorse".

Answer 3

PDO offre un'interfaccia piacevole ma più genericità significa anche più problemi per gestire le sottili idiosincrasie di ciascun back-end. Se guardi allo the bugtracker, ha un numero di problemi aperti e alcuni sono seri.

Ecco una prova aneddotica con postgresql: il parser di PDO ha problemi con le stringhe standard_conforming impostate su ON (che ora è l'impostazione predefinita, a partire da PG-9.1). caso di prova con 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")); 

Il execute() non riesce inaspettatamente a livello PDO con Database error: SQLSTATE[HY093]: Invalid parameter number: :foo. Sembra che non sia in grado di identificare: foo come parametro.

Se la query si interrompe dopo 'ab\'=:foo, senza un'altra condizione, quindi funziona correttamente. Oppure se l'altra condizione non include una stringa, funziona anche bene.

Il problema è simile a issue #55335, che è stato respinto come Non è un bug, a torto secondo me. [In realtà, ho persino hackerato PDO per ripararlo, ma in un modo che è incompatibile con altri backend, quindi nessuna patch. Ero sconcertato dal fatto che l'analizzatore lessicale della query fosse così generico.]

D'altra parte, pg_ * essendo più vicino a libpq, questo tipo di problema è meno probabile che accada in primo luogo, e più facile da risolvere se lo fa.

Quindi il mio punto è che non tutto è bello con PDO. Internamente, è sicuramente più difficile di pg_ *, e più complessità significa più bug. Questi bug sono stati risolti? Basato su determinate voci di bugtracker, non necessariamente.