PDO vs pg_ * funciones

Question

Ambos tienen declaraciones preparadas. pg_ * es un contenedor de libpq. ¿Derecha?

me gusta la DOP en PHP, pero no voy a cambiar la base de datos en el futuro. ¿Qué biblioteca debo usar? ¿Algún punto de referencia? versión PHP: 5,4

Answer 1

mi humilde opinión utilizando las funciones que los enfoques directamente hormigón DB (como pg_, oci_, mysql[i]_ etc.) es siempre un poco más rápido a continuación, utilizando una DOP o cualquier capa de DBMS (Doctrina, dibi, etc.) .

Pero usar DOP o cualquier capa de DBMS en la arquitectura OOP debería ser un mejor enfoque (en mi humilde opinión, de nuevo), a medida que aprende a utilizar esta capa y así la usará en cualquier motor de DB que esté detrás. Por supuesto, si cambia el motor de DB dentro de la aplicación, no tiene que molestarse en volver a escribir toda la aplicación.

Incluso si usted no está planeando cambiar el motor de base de datos que recomendaría el uso de la denominación de origen. Pero eso es sólo mi opinión :-)

Answer 2

creo que esto es más una cuestión de gusto. PDO puede ser más rápido ya que está compilado, o puede no serlo, ya que actúa como un contenedor. Estoy seguro de que la diferencia de velocidad sería lo suficientemente pequeña como para no afectar su decisión.

Esto es pura especulación, pero PDO es nuevo y parece ser la norma para las conexiones de base de datos ahora, para apoyo a la misma en los términos del código probablemente va a crecer, mientras que el apoyo a mysql_*pg_* y probablemente continuará a disminuir.

La principal ventaja de PDO es que su abstracción le permitirá cambiar a un DB diferente más tarde, pero apuesto a que no, por lo que probablemente tampoco deba influir en su decisión.

yo personalmente prefiero trabajar con PDO. Es más fácil pasar y controlar objetos que variables de "recursos".

Answer 3

DOP ofrece una interfaz agradable pero más genericity también significa más problemas para hacer frente a las idiosincrasias sutiles de cada servidor. Si nos fijamos en the bugtracker, tiene una serie de problemas abiertos, y algunos de ellos son graves.

He aquí una evidencia anecdótica con postgresql: el analizador de PDO tiene problemas con standard_conforming_strings establecido en ON (que ahora es el predeterminado, a partir de PG-9.1). caso de prueba 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")); 

La ejecutar() falla inesperadamente en la capa de DOP con Database error: SQLSTATE[HY093]: Invalid parameter number: :foo. Parece que no puede identificar: foo como parámetro.

Si la consulta se detiene después de 'ab\'=:foo, sin otra condición, entonces funciona bien. O si la otra condición no incluye una cadena, también funciona bien.

El problema es similar a issue #55335, que fue despedido como no un error, equivocadamente en mi opinión. [En realidad, incluso he pirateado PDO yo mismo para arreglarlo, pero de una manera que es incompatible con otros procesadores, por lo que no hay parche. Me desconcertó que el analizador léxico de consultas fuera tan genérico.]

Por otro lado, pg_ * estar más cerca de LIBPQ, este tipo de problema es menos probable que suceda en el primer lugar, y más fácil de resolver si lo hace.

Así que mi punto sería que no todo es agradable con DOP. Internamente, sin duda es más desafiante que pg_ *, y más complejidad significa más errores. ¿Se tratan estos errores? Basado en ciertas entradas de bugtracker, no necesariamente.