2011-07-08 288 views
19

Todo lo que he leído hasta ahora sobre PDO (Objetos de datos PHP) es casi demasiado bueno para ser cierto.Desventajas de PDO (objetos de datos PHP)

quiero decir:

  • Su más rápido que MySQL o mysqli.
  • Tiene la misma sintaxis para varios controladores de bases de datos.
  • con declaraciones preparadas, es seguro para inyección SQL.
  • puede buscar datos directamente en un objeto.

¿Pero cuáles son las desventajas de PDO?

+0

Lo mismo que siempre con PHP: escriba inseguro significa un desastre insoluble si el desarrollador no es disciplinado. Caza de insectos en el infierno Lo normal. – bdares

+2

@bdares En realidad, es bastante seguro, y tu argumento va en contra de PHP y su naturaleza, no en contra de PDO. –

+0

No sé a qué te refieres con la misma sintaxis para toda la base de datos. Si te refieres a sql, estás equivocado. Pdo es una capa de abstracción de acceso a datos y no una abstracción de base de datos, sql sigue siendo diferente. Si quiere decir hacer consultas, puede tener razón, pero escribir un envoltorio simple le proporciona lo mismo si quiere cambiar el tipo de base de datos. – frostymarvelous

Respuesta

15

Todo lo que he leído hasta ahora sobre PDO (objetos de datos PHP) es casi demasiado bueno para ser verdad.

Uso PDO todos los días, y eso por una razón. Sí escribí un contenedor, porque la instancia predeterminada de PDO hace cosas que no me gustan (por ejemplo, fallan silenciosamente), y la API podría haber sido mucho mejor. La configuración con constantes simplemente no es mi enfoque predeterminado. Además, he creado algunos métodos de conveniencia.

Es más rápido que mysql o mysqli.

¿Lo es? No sé de dónde sacó esto, y podría ser cierto, pero no he oído que PDO sea más rápido que las bibliotecas nativas de MySQL.

Tiene la misma sintaxis para varios controladores de bases de datos.

Tipo de. Uso PostgreSQL mucho, y el código es diferente de cuando estás trabajando con MySQL. Sin embargo, esto tiene sentido, ya que PostgreSQL funciona con secuencias con nombre, mientras que MySQL funciona con "incremento automático", que es una secuencia por tabla. Existen diferencias entre las bases de datos que PDO no puede abstraer, incluso si solo es para la base de datos , acceso.

con declaraciones preparadas es seguro para la inyección sql.

Usted también puede prepare statements with mysqli, así que no veo esto como un aspecto positivo definitivo. Sin embargo, en general uso declaraciones preparadas, y me gusta la sintaxis de campo que proporciona PDO.

Pero, ¿dónde están las desventajas de PDO, algo que tiene tantos profesionales también debe tener una contra.

La API es menos que intuitivo para mí, creo que la API de mysqli tiene más sentido. Sin embargo, si escribes un envoltorio para ti, es una biblioteca muy decente. Aquí está the wrapper I wrote para hacer que el uso de PDO sea un poco más sensato, aunque hay muchos más ejemplos a la deriva en Internet.

EDIT: Ah, y James Anderson tiene razón; tiene poca compatibilidad con Oracle. No uso Oracle, así que no lo veo como un gran inconveniente.

+1

PDO puede ser más rápido que mysql_ * cuando se usa una declaración preparada muchas veces ya que se necesitan enviar menos datos al servidor mysql para una declaración preparada, sin embargo no es más rápido cuando se hacen muchas declaraciones preparadas y se ejecutan pocas veces y definitivamente no más rápido que mysqli. – Mike

+1

En mi opinión PDO puede ser * más rápido que mysql * en ** no permitir/hacer más difícil para los programadores cojos sin antecedentes de base de datos decentes, pero un OO uno ** sólido, consultar el DB 26 veces con malas consultas en lugar de solo una con la consulta * derecha *. – ZJR

+0

^Esto multiplicado por un millón. – mopsyd

0

Recuerdo haber leído en alguna parte que una de las desventajas de PDO es que lleva un poco más de tiempo de consulta. (Lo siento, no tengo referencia a ese artículo), con suerte algunos expertos pueden contarlo.

3

dos inconvenientes, que yo sepa:

deficiente o nulo apoyo de Oracle!

Algunos resultados de rendimiento en grandes conjuntos de resultados.

En lo que a mí respecta, el primer "inconveniente" es otra razón para evitar Oracle. El segundo rara vez importa.

5

El mecanismo de vinculación no funciona con los nombres de columnas o tablas.

ejemplos simples:

CREATE TABLE :bar (rowId int) 

SELECT :foo FROM :bar 

En el lado positivo, esto no es algo que a menudo necesita o quiere hacer.

Pero cuando lo haces ... PDO te deja colgando. La solución se concating manualmente junto a sus cadenas de consulta mientras se hace por mano de escapar:

$foo = some_escape_logic($dirtyFoo); 
$bar = some_escape_logic($dirtyBar); 

$db->query("SELECT {$foo} FROM {$bar}"); 

resultados SQL siempre se devuelven como cadenas

fetch() devuelve una matriz de valores de cadena, incluso si la tabla de SQL los tipos son numéricos Por ejemplo, una mesa con BIGINT/cadena/columnas BIGINT devuelve:

array('rowId' => '1', 'name' => 'Fred', 'age' => '12'); 

en lugar de:

array('rowId' => 1, 'name' => 'Fred', 'age' => 12); 

Como positivo, que nunca se pierde la precisión de un desajuste entre PHP y SQL tipos. El tipo de malabarismo en PHP también asegura que rara vez se dará cuenta de que los datos fueron originalmente codificados como cadenas.

Como negativo, esto puede ser un dolor al pasar los resultados de base de datos a algo así como json_encode(), ya que va a terminar con los valores numéricos citados:

{ "rowId": "1", "name": "Fred", "age": "12" } 

en lugar de

{ "rowId": 1, "name": "Fred", "age": 12 } 

En un mundo ideal, los tipos de salida de autoenvío de fetch() serían controlables mediante un argumento opcional.

+0

Encontré el primer problema aquí hace algún tiempo. Resultó cuando supe lo suficiente que estaba haciendo el esquema de relación de la base de datos equivocado. Lo arreglé y nunca volví a encontrar este problema. De todos modos +1 –

+0

Los resultados SQL siempre se devuelven como cadenas - Parece ser el caso con el controlador mysql, pero no el controlador postgres. Si usa postgres con PDO, intentará asignar valores al tipo de PHP equivalente más cercano – GordonM

5

Es más rápido que mysql o mysqli.

mal. en la vida real es más lento en general.

Tiene la misma sintaxis para varios controladores de bases de datos.

para las funciones API - sí, por supuesto. pero no te ayudará con diferentes dialectos SQL.

con declaraciones preparadas es seguro para la inyección sql.

a estar asegurado contra las inyecciones SQL, cuatro asuntos necesitan ser adecuadamente escapado:

  • cadenas
  • números
  • identificadores
  • operadores

mientras DOP cubre solo abetos t dos.