php - mysqli_select_db - ¿Cambiar a mysqli o quedarse con mysql?
mysqli_real_escape_string (7)
Tenemos una aplicación aquí que ha estado en desarrollo (y ahora en producción) durante más de un año. Que tiene en total más de 500 llamadas mysql_* .
¿Vale la pena cambiar todo el mysql_* en el código a mysqli_*
¿Vale la pena perseguir todos los errores que podrían (y probablemente lo harán) surgir?
Veo por preguntas como esta: ¿ Cambiar esto de MySQL a MySQLi? que simplemente agregar i después de cada llamada a mysql* puede llevarme a muchos errores. ¿Vale la pena mi tiempo?
mysql_* probablemente esté a la vuelta de la mysql_* (incluso entre los rumores de desaprobación), por lo que realmente vale la pena que los programadores cambien metódicamente.
Citando el manual para ext/mysqli :
La extensión mysqli tiene una serie de ventajas, las mejoras clave sobre la extensión mysql son:
- Interfaz orientada a objetos
- Soporte para declaraciones preparadas
- Soporte para múltiples declaraciones
- Soporte para Transacciones
- Capacidades de depuración mejoradas
- Soporte de servidor integrado
Nota: Si está utilizando las versiones de MySQL 4.1.3 o posteriores, se recomienda encarecidamente que use esta extensión.
Si solo necesita una de esas características y puede pagar la refacturación, entonces sí, vaya por ella. Si no necesita ninguna de esas características, no lo haga. No hay razón para refactorizar si no hay beneficios.
En una nota al margen, los rumores son ciertos. Es probable que ext / mysql esté en desuso (aunque nadie puede decir cuándo en el momento de escribir este documento. Ciertamente no estará en desuso con 5.4. y probablemente estará disponible como una extensión pecl para siempre) En cualquier caso, no debería iniciar ninguna nuevos proyectos con ext / mysql más cuando tienes una extensión superior para empezar.
También vea http://blog.ulf-wendel.de/2012/php-mysql-why-to-upgrade-extmysql/
Consejo: Si vas a hacer un cambio, no cambies a mysqli, en cambio pasa a usar PDO. Si debe cambiar a mysqli, asegúrese de usarlo en PHP5 OO. No use mysqli OO y mysql antiguo al mismo tiempo o el viejo mysql y PDO al mismo tiempo a menos que le guste la interrupción inesperada de la conexión.
En mi opinión, el beneficio de MySQLi es cuando se usa de forma orientada a objetos y con declaraciones preparadas. Obtienes algo de versatilidad adicional usando el estilo de procedimiento también, como las funciones de envoltura agradable en el manejo de transacciones, pero creo que no es suficiente para justificar a menos que reescribas gran parte de tu código para hacer uso de ellos.
Y si realizara el esfuerzo de convertir a código OO o declaraciones preparadas, también podría convertir a la PDO más flexible en lugar de a MySQLi.
Actualización ene 2013
Acabo de encontrar esta vieja respuesta, y en el hilo de comentarios de agosto de 2011, a continuación, dije que no valía la pena convertir las llamadas a mysql_query() en ausencia de un movimiento de acompañamiento a las declaraciones preparadas. Ahora es necesario comenzar a avanzar en esa dirección, ya que la extensión mysql_*() está en desuso a partir de PHP 5.5 y eventualmente se eliminará.
En mi opinión, no deberías usar la función mysql_ * directamente en tu lógica. Deberías escribir un contenedor. Entonces, cuando desee cambiar mysql_* a mysqli_* , solo tiene que cambiar el código del contenedor.
La depreciación de ext / mysql no es un rumor.
Sin embargo, no es tu problema real.
Su principal problema es que está utilizando llamadas API desnudas en todo el código en lugar de utilizar alguna biblioteca inteligente para manejar consultas SQL.
Entonces, será mejor que comiences a desarrollar una biblioteca de ese tipo o que tengas una lista preparada, y luego reescribas tu código para usar sus llamadas.
No ves que todo este material repetido
$res=mysql_query("SELECT STUFF");
while($row = mysql_fetch){
$var=$row[''col''];
}
siendo increíblemente aburrido?
¿Por qué no usar algo como un trazador de líneas como
$data = $db->getRow("SELECT stuff");
¿Qué es más corto y puede tener muchas características como el registro de consultas, el conteo, la depuración, el manejo de errores y demás?
Y, como efecto secundario del uso de dicha biblioteca, el único lugar donde tendrá que cambiar las llamadas a API será solo este código de biblioteca.
MySQLi tiene algunas ventajas de rendimiento sobre MySQL. En realidad, se recomienda utilizar MySQLi en lugar de MySQL. Puedes hacer el estilo de procedimiento también.
Puede crear una nueva rama de su aplicación y cambiar el código a funciones mysqli_* . Esto debería ser bastante directo y, al hacerlo, revisaría su código de acceso a la base de datos que podría ayudar a continuar después del cambio a mysqli para continuar la refactorización. Si es demasiada molestia, ya se beneficia de la versión mejorada de la biblioteca del cliente en su código de acceso a la base de datos.
Si tiene tantas llamadas, le sugiero que empiece implementando (seleccionando o construyendo) una capa de abstracción para sus llamadas a la base de datos y luego conviértala.
El mayor beneficio (uno sustancial) en mi ejercicio similar fue el hecho de que mysqli ofrece declaraciones parametrizadas que te permiten dejar detrás mysql_real_escape_string, etc. Pero el mapa de uno a otro no es casi uno a uno.