Puis-je mélanger Api MySQL en PHP?

J'ai cherché sur le net et pour l'instant ce que j'ai vu, c'est que vous pouvez utiliser mysql_ et mysqli_ ensemble sens:

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

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

ou 

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

Sont valables, mais lorsque j'utilise ce code ce que je reçois est:

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

Pour la première et la même sauf avec mysqli_close(). Pour le deuxième.

Quel est le problème? Je ne peux pas utiliser mysql_ et mysqli ensemble? Ou est-ce normal? Est le moyen pour moi de vérifier si les connexions sont valides à tous? (le if(mysq...))

  • mysql est obsolète, il n'a de sens qu'ils ne travaillent pas ensemble. Pourquoi essayez-vous de le faire..?
  • Vous devriez éviter d'utiliser des mysql_* fonctions tout à fait. Elles sont sujettes à l'erreur et dangereux, et ils seront supprimés à partir de PHP bientôt (qu'ils soient marqués comme deprecated pour le moment). [Cette grande réponse][0] va dans la manière plus détaillée expliquant pourquoi ils sont mauvais. [0]:stackoverflow.com/a/12860046/1055295
  • 1) vous insistez sur l'utilisation d'une vieille mauvaise qualité de l'interface (mysql) qui est marqué comme obsolète dans la doc depuis des éons 2) pour une raison étrange, vous voulez mélanger avec son successeur au lieu de faire la bonne chose et de se convertir à la nouvelle 3) vous êtes tellement surpris qu'il ne fonctionne pas que vous vous posez sur DONC, à ce sujet, mais il devrait être assez évident que ce que vous faites est un non-sens.
  • double possible de mysql_fetch_array() s'attend à ce paramètre 1 pour être resource, boolean donné à sélectionner
  • Encore une autre superstition à être ajouté à des milliers d'autres. Tout le monde est sûr qu'il est honnête de la fonction est "erreurs", pas un programmeur, qui n'avait aucune idée de comment utiliser une fonction correctement et à peine aurait cette idée pour un nouveau.
  • Ce n'est pas une superstition. Bien sûr, vous pouvez écrire du mauvais code avec mysqli_* fonctions et le code de bonne avec mysql_* ceux. Mais la dernière catégorie est marquée comme obsolète car il est le point inférieur de fonctions, de ne pas être en mesure de soutenir OO-style invocations ou même des déclarations préparées à l'avance (pour ne citer que deux exemples). Étant donné un choix de deux outils pour faire le même travail, dont l'un est clairement mieux dans le long terme et plus souple, n'est pas la bonne réponse évidente?
  • En PHP il y a un helluvalot de fonctions n'étant pas en mesure de soutenir OO-style invocations qui personne ne va déprécier. Ce qui ne va pas avec eux?
  • Ce n'était pas le point principal que j'essayais de faire. L'absence de déclaration de soutien et de transactions est le plus gros problème.
  • Il ne manque pas de transactions. Êtes-vous vraiment faire croire que toutes ces années utilisateurs de PHP ont été incapables d'utiliser les transactions? Pouvez-vous le prouver?
  • Il n'y a pas de support direct, comme mysqli::begin_transaction. Tout ce que vous pouvez faire est un mysql_query("START TRANSACTION"). Et cela rend la gestion des erreurs de plus en plus lourde, alors que le mysqli variante déclenche une exception quand quelque chose se passe mal lors de la transaction. Cela rend le code beaucoup plus clair et plus facile à lire. Sans doute, vous avez juste à émuler cette fonctionnalité à l'aide d'une classe personnalisée et mysql_* appels, mais c'est un peu exagéré, comme il serait juste manuellement la mise en œuvre de la mysqli_* ceux.
  • Croyez-vous vraiment que l'API mysqli être utilisé comme il est, dans la forme brute d'appels de l'API de droit dans le code de l'application, sans une classe personnalisée pour être encapsulé dans? La recherche en récente de la question je frissonne avec la douleur de voir cette approche. Pensez-vous vraiment mysqli être utilisé de cette façon?
  • Bien sûr que non. Toutefois, compte tenu de l'option de choisir entre la fonctionnalité obsolète et activement soutenu l'une pour, disons, rouler votre propre abstraction, pourquoi utiliser les anciennes fonctions?
  • Pourquoi utiliser est une autre question (si j'étais dépourvu de choix). Mais j'ai demandé pourquoi la vieille mysql ext est "erreurs" et "dangereux". Et vous n'avez pas à fournir une preuve, me nourrissant avec la plaine de faux (ne prend pas en charge les transactions et autres) ou inutiles (style procédural) trucs. Mais la vérité est qu'il n'y a rien de mal avec mysql ext enregistrer pour ses utilisateurs. Et ces utilisateurs ne sont pas devenus de bons en changeant juste les noms des fonctions qu'ils utilisent.
  • Oui, j'ai reconnu que, dès le début - " Ce n'est pas une superstition. Bien sûr, vous pouvez écrire du mauvais code avec mysqli_* les fonctions et le code de bonne avec mysql_* les principes. `. Et par sujettes à l'erreur, j'ai surtout s'agissant de l'absence de déclarations préparées à l'avance. Vous pouvez échapper les données avant de les concaténer à la requête, bien sûr, mais il est très facile d'oublier un champ introduisant ainsi une vulnérabilité. Avec des déclarations préparées à l'avance, c'est impossible. Encore une fois, cela est lié plus pour le programmeur que pour les outils, donc comme vous l'avez dit -, le programmeur est ce qui importe le plus à la fin.
  • Dans cette classe personnalisée qui nous avons convenu, qui doivent être utilisées de toute façon, on peut utiliser un émulé déclarations préparées à l'avance tout droit, par exemple, peut être vu à droite dans la réponse à côté de l'un est lié à l'. Donc, rien de mal avec l'API de nouveau. Dire que mysql ext est sujette aux erreurs et à l'insalubrité est une simple superstition. Ou - si vous aimez cette façon - un conte effrayant destiné à permettre à une dépréciation. Mais il n'y a rien de mal avec mysql poste lui-même et ne l'ont jamais été. La très PHP utilisateur qui est aussi impuissant que être dans l'incapacité d'utiliser quoi que ce soit mais raw appels de l'API dans le code de l'application est le seul problème.
  • Je suis maintenant convaincu par vos arguments; manifestement, vous avez plus d'expérience que moi. Mais alors pourquoi les mysql_* extensions marqué comme obsolète?
  • Pour autant que je sais, c'est juste des gens qui responsable pour le support de l'extension décidé de laisser tomber. PHP équipe n'est pas seulement les gens qui prend en charge diverses extensions. Dire, Microsoft est responsable pour le support de Windows. Et ils ont abandonné XP support que de la récente 5.5. En va de même pour mysql - il de l'Oracle des gens qui maintiennent l'extension et ils ont décidé de laisser tomber. Aussi simple que cela. Pourtant, je crois que l'intention a été en grande partie pris en charge par la communauté en raison de la très même fausse croyance, nous avons discuté ici.
  • cela devrait éclairer: wiki.php.net/rfc/mysql_deprecation
  • Je vois. Merci pour l'information. Eh bien, je suppose que les requêtes asynchrones, pourrait être une autre chose qui est important pour une haute performance de l'application web. Je n'ai pas mentionné, mais, depuis que j'ai jusqu'à présent n'ont pas utilisé personnellement.

InformationsquelleAutor N3mo | 2013-07-05
  1. 61

    Non, vous ne pouvez pas utiliser mysql et mysqli ensemble. Ils sont séparés les Api et les ressources qu'ils créent sont incompatibles les uns avec les autres.

    Il y a un mysqli_close, si.

    • Bien que vous ne devriez jamais avoir besoin de fermer la connexion de toute façon; les objets de nettoyer eux-mêmes quand elles ne sont plus référencés. (Pas sûr que ce soit clair vieille ressources, mais les objets peuvent réellement profiter de RAII pour un non-négligeable degré.)
    • non seulement cela, mais PHP va fermer toutes les connexions MySQL lorsque le script se termine
    • Mais pas toujours, à mon expérience, de sorte que nous avons toujours mis un proche à la fin du fichier.
    InformationsquelleAutor Explosion Pills
  2. 12

    Juste pour donner une réponse générale, ici, toutes les trois API MYSQL avec une référence:

    Vous ne pouvez pas combiner l'une des trois (mysql_*, mysqli_*, PDO) API MYSQL de PHP, il ne fonctionne tout simplement pas. C'est même dans la manuel FAQ:

    Il est pas possible de mélanger les extensions. Ainsi, par exemple, le passage d'une connexion mysqli à PDO_MySQL ou ext/mysql ne fonctionnera pas.

    Vous devez utiliser la même API MySQL et de ses fonctions, à partir d'une connexion à l'interrogation.

    • Un mec a essayé de me dire aujourd'hui qu'ils n'ont pas de problème d'erreurs lors du mélange de mysql_real_escape_string() avec ce que le reste de leur code d'AOP. Est-il quelque chose que je n'ai pas ici de mon temps à travailler avec ces différents Api? Suis-je le ignorants ici? Ceci étant pour le "maintenant supprimé" question stackoverflow.com/q/34209127 seulement visible par les 10K+ membres si quelqu'un me demande. Ceci par rapport à la $stmt3->execute(array('classID' => $_POST['class'],'studentID' => mysql_real_escape_string($substr))) - Suis-je manqué quelque chose?
    • Vous avez raison 🙂 la Lecture de la manuel, montre que vous êtes correct. Ce qui est probablement arrivé est que mysql_real_escape_string() silencieusement essayer établir une connexion avec les paramètres par défaut qui a ensuite travaillé pour l'OP. Il était donc le lien pour obtenir le jeu de caractères. Si l'OP a 2 connexions
    • Si l'OP a eu au moins m'a dit/qu'ils avaient probablement 2 séparer les connexions, j'aurais probablement accepté; ils ont décidé autrement. Cependant, je ne vois toujours pas comment cela fonctionne encore. Si c'est le cas, je suis perplexe.
    • Voir: link_identifier Il va utiliser les paramètres de connexion par défaut, qu'il obtient avec ini_get(). Donc, il est probablement juste de travaux pour l'OP avec les paramètres par défaut. Je voudrais juste laisser et obtenir de nouveau à café (☕☕☕).
    • Vous aimeriez ajouter quelque chose à propos de sqlsrv_query(). J'ai juste fermé une question ici stackoverflow.com/q/41263771
    • vous avez raison, mysql_real_escape_string ne doivent absolument pas être mélangé avec PDO, et si vous le faites alors les vulnérabilités d'injection SQL et incorrectement échappé chaînes sont susceptibles de se produire. cela dit, l'AOP-version de mysql_real_escape_string() est appelé PDO::quote(), mais attention: quote() ajoute des guillemets autour de la chaîne, mysql_real_escape_string ne pas, donc $str="'".mysql_real_escape_string($str)."'"; se traduit par $str=$pdo->quote($str);, PAS $str="'".$pdo->quote($str)."'"; que l'on pourrait penser quand le portage.

    InformationsquelleAutor Rizier123
  3. 2

    Techniquement, vous pouvez utiliser le plus grand nombre de connexions que vous voulez, tandis que votre problème est causé par une simple faute de frappe - vous seulement ne peuvent pas utiliser les ressources d'une extension des fonctions de l'autre, ce qui est bien évidemment.

    Cependant, vous devrait éviter de multiples connexions avec le même script, peu importe à partir de unique de l'API ou de de différentes. Comme il aura la charge de votre serveur de base de données et épuiser ses ressources. Donc, même si, techniquement, vous pouvez, vous ne devriez pas mélanger différentes extensions dans votre code, enregistrer de la courte période de refactoring.

    • Alors que c'est probablement une bonne idée, mais le regroupement de connexion a été développé pour cette raison. Lorsque vous avez plusieurs demandes web de frapper un serveur web, vous ne pouvez pas facilement utiliser la même connexion, de sorte que vous ouvrez une nouvelle connexion. Le regroupement de connexion enregistre la surcharge sur le serveur d'applications et la base de données.
    InformationsquelleAutor Your Common Sense
  4. -3

    MySQLi est beaucoup plus sécurisé que MySQL qui de toute façon est maintenant obsolète. C'est pourquoi vous devriez coller avec MySQLi et aussi vous ne pouvez pas les mélanger car ils sont à la fois différentes.

    InformationsquelleAutor