26-11-2009, 10:18 AM
Le coup de la table temporaire n'est pas stupide, mais ça me paraît être beaucoup de travail pour rien.
Je ne vois personnellement pas d'intérêt aux requêtes préparées en php. Je m'explique : à chaque exécution de script, on ouvre une nouvelle connexion à la base. Les requêtes préparées étant spécifiques à une session MySQL particulière, elles sont effacées à chaque déconnexion à chaque fin de script et de nouveau repréparées à chaque fois que le script est réexécuté. Gain ? zéro. A part si on effectue plusieurs fois la même requête, mais ça me paraît plutôt rare (on peut grouper plusieurs update dans un replace et plusieurs select id dans un select where id in).
A moins que ja'i raté quelque chose et qu'on puisse préparer des requêtes au niveau du serveur.... mais alors pour moi c'est des procédures stockées, plus des requêtes préparées.
Perso pour les select in, je procède ainsi, et ça fonctionne très bien :
Je ne vois personnellement pas d'intérêt aux requêtes préparées en php. Je m'explique : à chaque exécution de script, on ouvre une nouvelle connexion à la base. Les requêtes préparées étant spécifiques à une session MySQL particulière, elles sont effacées à chaque déconnexion à chaque fin de script et de nouveau repréparées à chaque fois que le script est réexécuté. Gain ? zéro. A part si on effectue plusieurs fois la même requête, mais ça me paraît plutôt rare (on peut grouper plusieurs update dans un replace et plusieurs select id dans un select where id in).
A moins que ja'i raté quelque chose et qu'on puisse préparer des requêtes au niveau du serveur.... mais alors pour moi c'est des procédures stockées, plus des requêtes préparées.
Perso pour les select in, je procède ainsi, et ça fonctionne très bien :
Code :
$result = $db->query(sprintf('select ... from ... where id in(%s)', implode(',',$list)));
html, javascript, blagues, midi, etc. => http://quentinc.net/