php - strip_tags - mysqli o DOP: ¿cuáles son los pros y los contras?
strip_tags wordpress (13)
Aquí hay algo más que tener en cuenta: por ahora (PHP 5.2) la biblioteca de PDO tiene errores . Está lleno de bichos extraños. Por ejemplo: antes de almacenar un PDOStatement
en una variable, la variable debe ser unset()
para evitar una tonelada de errores. La mayoría de estos se han corregido en PHP 5.3 y se lanzarán a principios de 2009 en PHP 5.3, que probablemente tendrá muchos otros errores. Debería concentrarse en usar PDO para PHP 6.1 si desea una versión estable y usar PDO para PHP 5.3 si desea ayudar a la comunidad.
En nuestro lugar, estamos divididos entre el uso de mysqli y PDO para cosas como declaraciones preparadas y soporte de transacciones. Algunos proyectos usan uno, otros el otro. Hay pocas posibilidades realistas de que nos mudemos a otro RDBMS.
Prefiero PDO por la única razón de que permite parámetros con nombre para declaraciones preparadas, y hasta donde sé, mysqli no lo hace.
¿Existen otros pros y contras para elegir uno sobre el otro como estándar a medida que consolidamos nuestros proyectos para utilizar solo un enfoque?
Bueno, podría discutir el aspecto orientado a objetos, las declaraciones preparadas, el hecho de que se convierta en un estándar, etc. Pero sé que la mayoría de las veces, convencer a alguien funciona mejor con una función asesina. Así que ahí está:
Algo realmente bueno con la DOP es que puede obtener los datos, inyectándolos automáticamente en un objeto. Si no quieres usar un ORM (porque es solo un script rápido) pero te gusta el mapeo de objetos, es realmente genial:
class Student {
public $id;
public $first_name;
public $last_name
public function getFullName() {
return $this->first_name.'' ''.$this->last_name
}
}
try
{
$dbh = new PDO("mysql:host=$hostname;dbname=school", $username, $password)
$stmt = $dbh->query("SELECT * FROM students");
/* MAGIC HAPPENS HERE */
$stmt->setFetchMode(PDO::FETCH_INTO, new Student);
foreach($stmt as $student)
{
echo $student->getFullName().''<br />'';
}
$dbh = null;
}
catch(PDOException $e)
{
echo $e->getMessage();
}
En el sentido de la velocidad de ejecución, MySQLi gana, pero a menos que tenga un buen envoltorio que use MySQLi, sus funciones relacionadas con las declaraciones preparadas son terribles.
Todavía hay errores en la mía, pero si alguien lo quiere, aquí está .
En resumen, si está buscando una ganancia de velocidad, entonces MySQLi; Si quieres facilidad de uso, entonces DOP.
En mi script de referencia , cada método se prueba 10000 veces y se imprime la diferencia del tiempo total para cada método. Debe hacerlo en su propia configuración, estoy seguro de que los resultados variarán!
Estos son mis resultados:
- "
SELECT NULL" -> PGO()
más rápido por ~ 0.35 segundos - "
SHOW TABLE STATUS" -> mysqli()
más rápido por ~ 2.3 segundos - "
SELECT * FROM users" -> mysqli()
más rápido por ~ 33 segundos
Nota: al usar -> fetch_row () para mysqli, los nombres de las columnas no se agregan a la matriz, no encontré una forma de hacerlo en PGO. Pero incluso si uso -> fetch_array (), mysqli es ligeramente más lento pero aún más rápido que PGO (excepto SELECT NULL).
Hay una cosa a tener en cuenta.
Mysqli no admite la función fetch_assoc () que devolvería las columnas con claves que representan nombres de columnas. Por supuesto, es posible escribir su propia función para hacer eso, ni siquiera es muy largo, pero me costó mucho escribirlo (para los no creyentes: si le parece fácil, inténtelo usted mismo por un tiempo y no lo haga) t tramposo :))
He empezado a usar PDO porque, en mi opinión, el soporte de la declaración es mejor. Estoy usando una capa de acceso a datos ActiveRecord-esque, y es mucho más fácil implementar sentencias generadas dinámicamente. El enlace de parámetros de MySQLi se debe realizar en una sola función / llamada de método, por lo que si no sabe hasta el tiempo de ejecución cuántos parámetros le gustaría vincular, se call_user_func_array()
obligado a usar call_user_func_array()
(creo que ese es el nombre de la función correcta ) para selecciona. Y olvídate de la simple vinculación dinámica de resultados.
Más que nada, me gusta la DOP porque es un nivel de abstracción muy razonable. Es fácil de usar en sistemas completamente abstractos en los que no desea escribir SQL, pero también facilita el uso de un sistema de consultas puras más optimizado, o para mezclar y combinar las dos.
La DOP es el estándar, es lo que la mayoría de los desarrolladores esperan usar. mysqli fue esencialmente una solución a medida para un problema particular, pero tiene todos los problemas de las otras bibliotecas específicas de DBMS. DOP es donde irá todo el trabajo duro y el pensamiento inteligente.
Mover una aplicación de una base de datos a otra no es muy común, pero tarde o temprano puede que esté trabajando en otro proyecto utilizando un RDBMS diferente. Si está en casa con DOP, entonces habrá al menos una cosa que aprender en ese momento.
Aparte de eso, encuentro que la API de DOP es un poco más intuitiva y se siente más orientada a los objetos. mysqli siente que es solo una API de procedimiento que se ha objetivado, si sabes a qué me refiero. En resumen, me parece más fácil trabajar con la DOP, pero eso es, por supuesto, subjetivo.
Otra diferencia notable (buena) acerca de la DOP es que su método PDO::quote()
agrega automáticamente las comillas mysqli::real_escape_string()
, mientras que mysqli::real_escape_string()
(y similares) no:
PDO :: quote () coloca comillas alrededor de la cadena de entrada (si es necesario) y escapa de los caracteres especiales dentro de la cadena de entrada, utilizando un estilo de cita apropiado para el controlador subyacente.
PDO hará que sea mucho más fácil de escalar si su sitio / aplicación web se pone realmente como puede configurar diariamente las conexiones Maestro y Esclavo para distribuir la carga en la base de datos, además de que PHP se dirige a pasar a PDO como estándar.
Personalmente uso DOP, pero creo que es principalmente una cuestión de preferencia.
PDO tiene algunas características que ayudan a la inyección de SQL ( declaraciones preparadas ), pero si tiene cuidado con su SQL, también puede lograrlo con mysqli.
Mudarse a otra base de datos no es tanto una razón para usar DOP. Siempre y cuando no utilice "funciones SQL especiales", puede cambiar de una base de datos a otra. Sin embargo, tan pronto como use, por ejemplo, "SELECCIONE ... LÍMITE 1", no podrá ir a MS-SQL donde está "SELECCIONAR TOP 1 ...". Así que esto es problemático de todos modos.
Una cosa que PDO tiene que MySQLi no me gusta es la capacidad de PDO de devolver un resultado como un objeto de un tipo de clase específico (por ejemplo, $pdo->fetchObject(''MyClass'')
). Fetch_object fetch_object()
de fetch_object()
solo devolverá un objeto stdClass
.
Respuesta editada.
Después de tener alguna experiencia con estas dos API, diría que hay dos funciones de nivel de bloqueo que hacen que mysqli sea inutilizable con declaraciones preparadas de forma nativa.
Ya se mencionaron en 2 respuestas excelentes (aunque infravaloradas):
- Valores vinculantes a número arbitrario de marcadores de posición
- Devolviendo datos como una simple matriz
(ambos también mencionados en esta respuesta )
Por alguna razón mysqli falló con ambos.
Hoy en día se mejoró el segundo ( get_result ), pero funciona solo en las instalaciones de mysqlnd, lo que significa que no puede confiar en esta función en sus scripts.
Sin embargo, no tiene una vinculación por valor, incluso hasta el día de hoy.
Entonces, solo hay una opción: DOP
Todas las otras razones, tales como
- marcadores de posición nombrados (esta sintaxis de azúcar está sobrevalorada)
- Soporte de bases de datos diferentes (en realidad nadie lo usó)
- Fetch en objeto (sólo azúcar sintaxis inútil)
- diferencia de velocidad (no hay ninguna)
No tienen ninguna importancia significativa.
Al mismo tiempo, estas dos API carecen de algunas características realmente importantes , como
- identificador de posición
- marcador de posición para los tipos de datos complejos para que la vinculación dinámica sea menos complicada
- Código de aplicación más corto.
Entonces, para cubrir las necesidades de la vida real , uno tiene que crear su propia biblioteca de abstracción, basada en una de estas API, implementando marcadores de posición analizados manualmente. En este caso, preferiría mysqli, ya que tiene un menor nivel de abstracción.