Discussion :

[bonjourajax]

Bonsoir,

Dans une requête préparée avec mysqli

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
$stmt->execute();
$res=$stmt->get_result();
$assoc=$res->fetch_assoc();

Sur la doc ils utilisent directement

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
$stmt->close();

Donc y a t il besoin de faire (en plus) ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
$res->free();

comme dans une requête non préparée

[Invité]

Bonjour,

Ça ne sert à rien d'ouvrir et fermer 1000 fois la connexion.

On ouvre en début de script, on ferme à la fin.
Une fois pour toutes.

N.B. close et free ne servent pas à la même chose.
RELIS la DOC.

[bonjourajax]

Merci de votre réponse.
free result

Note:

Vous devriez toujours libérer les résultats avec mysqli_free_result(), lorsque votre objet de résultat ne vous est plus utile.

execute()
Ici ils combinent la requête préparée avec une requête normale

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
$query = "SELECT Name, CountryCode, District FROM myCity";
if ($result = $mysqli->query($query)) {
    while ($row = $result->fetch_row()) {
        printf("%s (%s,%s)\n", $row[0], $row[1], $row[2]);
    }
    /* Libère le résultat */
    $result->close();
}

Et la il le libere avec close ? J'ai du louper un truc

Y a aucun exemple de requête préparée avec fetch assoc

Les connexions et les jeux de résultats ouverts de facçon non persistents sont automatiquement détruits lorsqu'un script PHP termine son exécution. Aussi, le fait de fermer une connexion et libérer les résultats étant optionnel, le fait de le faire explicitement est néanmoins vivement recommandé. Ceci va retourner les ressources immédiatement à PHP et à MySQL, ce qui va améliorer les performance. Pour plus d'informations, référez-vous à la libération des ressources

[Celira]

close

Ferme une requête préparée. mysqli_stmt_close() libère le pointeur utilisé par stmt. Si la requête est en attente ou bien que les résultats ne sont pas encore lus, cette fonction les annulera et, donc, la prochaine requête pourra être exécutée.

free_​result

Libère le résultat stmt de la mémoire. stmt a été obtenu de la fonction mysqli_stmt_store_result().

Pour moi, si tu as utilisé store_result, il faut utiliser free_result. Par contre, close ne me parait pas indispensable, sauf si tu n'as pas lu la totalité des résultats de la requête précédente (genre un seul fetch pour un résultat à plusieurs lignes)

Cela dit, je n'utilise pas mysqli (que je trouve inutilement compliqué par rapport à PDO), donc il est possible que ce que je dis ne soit pas exact.

[bonjourajax]

A croire que jaime me compliquer la vie

pour mysqli j'utilise plutot get_result() pour un fetch assoc
Mais ce site la est vraiment mal foutu
Ils mettent des commentaires qui ne corespondent pas aux définitions ou inversement donc on se perd facilement
et il manque d'explication

exemple
j'ai du passer des heures pour trouver une solution pour passer un array a bind_param
c'est vrai qu'a ce niveau PDO est beaucoup plus simple

[Invité]

Un jour ou l'autre, tu devras passer à PDO.
Autant le faire tout de suite.

[bonjourajax]

Comment ça un jour ou l'autre?

[Invité]

Le seul "intérêt" de mysqli_ était de faire la transition avec mysql_ pour ceux qui l'utilisaient, et la syntaxe "ressemblait" (essentiellement en procédural donc).

PDO est le (futur) standard.
Et à l'usage, il est beaucoup plus pratique (notamment pour les requêtes préparées).

Tu trouveras aussi plus facilement des tutos en PDO :

• Comprendre PDO
• PDO une soupe et au lit !

[bonjourajax]

Est-ce qu'il y aurait aussi une différence en terme de performances ou les 2 se tiennent

apres c'est plus le style procédural de mysqli qui est assez chiant a utiliser, puis les fonctions ne retournent pas toutes la meme chose entre le style orienté objet et le style procédural (testé sur mysqli_num_row)
donc faut vraiment choisir entre soit l un soit l'autre soit PDO

[Invité]

Une recherche rapide... :

• PDO vs MySQLi speed comparison

Remarque : si on regarde le code fourni en test, c'est un peu faussé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
for ($i = 0; $i < NUMBER_OF_QUERIES_TO_TEST; $i++) {	
...
  $stmt = $conn_pdo->prepare("SELECT ..........");

La requête est préparée à chaque tour de roue !
Alors que dans la (bonne) pratique, on la prépare une fois pour toutes (avant le for).

[bonjourajax]

Ouais donc pour les requete preparée c'est plus rapide PDO

Apres cest dommage que le gars est re préparée la requête a chaque fois au lieu de juste changer les valeur de variable dans ces boucle ca aurait été intéressant davoir ce comparatif la aussi

edit: pas vu l'édit de ton message

->oui c'est normal car bind_param() prend des références en parametres (chez mysqli)

[Invité]

Tu peux aussi jeter un oeil à cette discussion.

[Celira]

Bon j'ai fait mon petit test dans mon coin (en partant de cet article : https://www.jimwestergren.com/pdo-versus-mysqli), et je trouve que pdo est légèrement plus rapide pour les requêtes préparées, alors que mysqli est légèrement plus rapide pour la version "à l'ancienne" (de l'ordre de 2%)

Par contre, je pense que c'est volontaire de préparer la requête à chaque tour de boucle : on tente de voir combien de temps ça prend pour exécuter N requêtes, pas N fois la même requête. Le but est de comparer PDO VS mysqli sur le même type d'exécution, et non pas requêtes préparées VS requêtes manuelles.

[bonjourajax]

Merci de vos réponses.

Par rapport a la question principale je pense qu'il vaut mieux tout utiliser
Et free_result obligatoire, Pour être sur qu'il n'y ait pas encore de résultats en mémoire qui influencerait sur la prochaine requête
$result->free()
stmt->close()


Puis à la fin du code:
mysqli->close()

Ce probleme se résout dans les requêtes non préparées grace aux functions next_result() et more_result() utilisées pour une multi_query