¿Puedo mezclar las API de MySQL en PHP?


106

He buscado en la red y hasta ahora lo que he visto es que pueden usar mysql_y mysqli_juntos significa:

<?php
$con=mysqli_connect("localhost", "root" ,"" ,"mysql");

if( mysqli_connect_errno( $con ) ) {
    echo "failed to connect";
}else{
    echo "connected";
}
mysql_close($con);
echo "Done";
?>

o

<?php
$con=mysql_connect("localhost", "root" ,"" ,"mysql");
if( mysqli_connect_errno( $con ) ) {
    echo "failed to connect";
}else{
    echo "connected";
}
mysqli_close($con);
echo "Done";
?>

Son válidos pero cuando uso este código lo que obtengo es:

Connected
Warning: mysql_close() expects parameter 1 to be resource, object given in D:\************.php on line 9
Done

Para el primero y el mismo excepto con mysqli_close(). Para el segundo.

¿Cuál es el problema? ¿No puedo usar mysql_y mysqlijuntos? ¿O es normal? ¿Es la forma en que puedo comprobar si las conexiones son válidas? (el if(mysq...))


5
mysql está en desuso, solo tiene sentido que no funcionen juntos. ¿Por qué intentas hacerlo ...?
Sterling Archer

7
Debe evitar el uso de mysql_*funciones por completo. Son propensos a errores e inseguros, y pronto se eliminarán de PHP (están marcados como obsoletos en este momento). [Esta gran respuesta] [0] explica con más detalle por qué son malos. [0]: stackoverflow.com/a/12860046/1055295
Andrei Bârsan

2
1) insiste en usar una interfaz vieja y de mala calidad (mysql) que está marcada como obsoleta en el documento desde hace eones 2) por alguna extraña razón, desea mezclarla con su sucesor en lugar de hacer lo correcto y convertirlo a uno nuevo 3 ) estás tan sorprendido de que no funcione que le preguntas al SO, aunque debería ser bastante obvio que lo que estás haciendo es una tontería.
fvu

1
No es una superstición. Por supuesto, puede escribir código incorrecto con mysqli_*funciones y código bueno con mysql_*otras. Pero la última categoría está marcada como obsoleta ya que es el conjunto inferior de funciones, no pudiendo admitir invocaciones de estilo OO o incluso declaraciones preparadas (por nombrar solo dos ejemplos). Dada la opción de dos herramientas para hacer el mismo trabajo, una de las cuales es claramente mejor a largo plazo y más flexible, ¿no es obvia la respuesta correcta?
Andrei Bârsan

1
Por supuesto no. Sin embargo, dada la opción de elegir entre la funcionalidad obsoleta y la soportada activamente para, digamos, desarrollar su propia abstracción, ¿por qué usar las funciones antiguas?
Andrei Bârsan

Respuestas:


65

No, no puedes usar mysqly mysqlijuntos. Son API independientes y los recursos que crean son incompatibles entre sí.

Sin mysqli_closeembargo, hay un .


Aunque nunca debería necesitar cerrar la conexión de todos modos; los objetos se limpian solos cuando ya no se hace referencia a ellos en ninguna parte. (No estoy seguro de si los recursos antiguos simples hacen eso, pero los objetos pueden aprovechar RAII en un grado no insignificante.)
cHao

@cHao no solo eso, sino que PHP cerrará cualquier conexión MySQL abierta cuando el script salga
Explosion Pills

1
Pero no siempre, según mi experiencia, por lo que siempre colocamos un cierre en la parte inferior del archivo.
RationalRabbit

14

Solo para dar una respuesta general aquí sobre las tres API de MYSQL con una referencia:

No se puede mezclar cualquiera de los tres ( mysql_*, mysqli_*, PDOMySQL API) de PHP de juntas, simplemente no funciona. Incluso está en el manual de preguntas frecuentes :

No es posible mezclar las extensiones . Entonces, por ejemplo, pasar una conexión mysqli a PDO_MySQL o ext / mysql no funcionará .


Debe utilizar la misma API de MySQL y sus funciones relacionadas, desde la conexión hasta la consulta.


Un tipo intentó decirme hoy que no tienen problemas / errores al mezclar mysql_real_escape_string()con el resto de su código que es PDO. ¿Hay algo que no logré en mi tiempo trabajando con estas diferentes API? ¿Soy yo el ignorante aquí? Esto es para la pregunta "ahora eliminada" stackoverflow.com/q/34209127 solo visible para más de 10K miembros si alguien se pregunta. Esto en relación con $stmt3->execute(array('classID' => $_POST['class'],'studentID' => mysql_real_escape_string($substr))): ¿Me estoy perdiendo algo aquí?
Funk Forty Niner

1
@ Fred-ii- Tienes razón :) La lectura del manual demuestra que estás en lo cierto . Lo que probablemente ocurrió es, que mysql_real_escape_string()será en silencio intentar establecer una conexión con los parámetros por defecto que entonces trabajaban para OP. Así que simplemente hizo la conexión para obtener el juego de caracteres. Entonces OP tiene 2 conexiones
Rizier123

Si el OP al menos me hubiera dicho / nos hubiera dicho que probablemente tenían 2 conexiones separadas, probablemente hubiera estado de acuerdo; decidieron lo contrario. Sin embargo, todavía no veo cómo funcionaría eso. Si es así, estoy desconcertado.
Funk Forty Niner

@ Fred-ii- Ver: link_identifier Utilizará la configuración de conexión predeterminada, con la que obtiene ini_get(). Entonces probablemente solo funcione para OP con la configuración predeterminada. Lo dejaría y tomaría un café nuevo (☕☕☕).
Rizier123

Es posible que desee agregar algo sobre sqlsrv_query(). Acabo de cerrar una pregunta aquí stackoverflow.com/q/41263771
Funk Forty Niner

2

Técnicamente, puede usar tantas conexiones separadas como desee, mientras que su problema se debe a un mero error tipográfico: solo no puede usar recursos de una extensión con funciones de otra, lo cual es bastante obvio.

Sin embargo, debe evitar múltiples conexiones desde el mismo script , sin importar si son API únicas o diferentes. Ya que cargará su servidor de base de datos y agotará sus recursos. Entonces, aunque técnicamente puede, no debe mezclar diferentes extensiones en su código, excepto durante el corto período de refactorización.


Aunque probablemente sea una buena idea, la agrupación de conexiones se desarrolló por este motivo. Cuando tiene varias solicitudes web que llegan a un servidor web, no puede usar fácilmente la misma conexión, por lo que abre una nueva conexión. La agrupación de conexiones ahorra la sobrecarga en el servidor de aplicaciones y la base de datos.
Doug

-3

MySQLies mucho más seguro que lo MySQLque ahora está en desuso. Es por eso que debes quedarte MySQLiy tampoco puedes mezclarlos, ya que ambos son diferentes.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.