PDO : select in (...) - Version imprimable +- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org) +-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38) +--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51) +--- Sujet : PDO : select in (...) (/showthread.php?tid=4461) |
PDO : select in (...) - Ter Rowan - 26-11-2009 plop plop je n'ai encore jamais essayé d'utiliser pdo mais je l'envisage et je me pose la question d'une requête qui serait du type Code PHP :
avec $liste les bonnes valeurs j'ai cherché dans google et rien trouvé à part ce post un peu vieux la réponse qui tue qui m'a bien fait rire Evidemment, j'ignore à l'avance le nombre d'éléments dans liste, il peut y en avoir 1 2 3 4.... ayant exactement les mêmes problématique que l'auteur du lien ci dessus, je voulais savoir si il était possible de s'appuyer sur des requêtes préparées ou si il fallait que j'utilise les requêtes standards ? merci d'avance RE: PDO : select in (...) - DragonMaster - 26-11-2009 Sa n'a probablement pas rapport...mais pourquoi souhaites-tu utiliser sa? Je veux dire je ne vois pas particulièrement de situation ou c'est profitable. RE: PDO : select in (...) - NicoMSEvent - 26-11-2009 tu pourrais mettre les éléments du IN dans une petite table (appelons la table_in), et ensuite faire : Code : $req = "SELECT toto FROM tata WHERE titi in ( SELECT id FROM table_in )"; Code : $req = "SELECT toto FROM tata JOIN table_in ON tata.titi =table_in.id"; l'inconvénient est de devoir remplir ta table, et la vider a chaque fois que tu changes les valeurs a mettre dans le "IN". L'avantage est que ça marchera dans tous les cas RE: PDO : select in (...) - QuentinC - 26-11-2009 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 : Code : $result = $db->query(sprintf('select ... from ... where id in(%s)', implode(',',$list))); RE: PDO : select in (...) - php_addict - 26-11-2009 bonjour je me permet une question annexe: est ce que dans une requete Code : $req = "SELECT toto FROM tata WHERE titi in ( $liste )"; si pendant la boucle on ajoute un element à la liste, est ce que cet element est pris en compte dans la requete? d'apres ce que j'ai pu tester c'est non, mais est ce possible de le faire? autrement dit: dans une requete avec WHERE in ($liste) est ce possible d'ajouter des elements à la $liste ? a+ RE: PDO : select in (...) - QuentinC - 26-11-2009 Citation :si pendant la boucle on ajoute un element à la liste, est ce que cet element est pris en compte dans la requete?Non, et c'est pas possible. Il faut faire une autre requête. Tu me poses une question, je te réponds. Pendant que je te réponds, tu t'aperçois que tu as oublié quelque chose..... tu es obligé de me laisser finir de parler et ensuite tu devras me demander ce que tu as oublié. Je ne peux ni lire dans tes pensées ni t'écouter pendant que je te parle, donc je ne peux pas répondre à la question que tu te poses dans ta tête après avoir obtenu une partie de réponse. Ben là c'est pareil ! Pour parler plus techniquement : on ne fait qu'une requête à la fois. Si tu as des liaisons récursives dans tes tables, tu n'as pas le choix que de faire des requêtes successives, sinon il y a peut-être un moyen de tout inclure dès le début avec des jointures. RE: PDO : select in (...) - Ter Rowan - 26-11-2009 merci pour vos réponses pour la table in, ce n'est pas pertinent pour les cas auxquels je pense en effet, l'objectif de mes requêtes avec "in" est d'éviter de charger unitairement plusieurs instances d'une même classe (personnage, item d'inventaire, etc...) or j'ai besoin pour toute interaction (personnage-personnage, personnage-équipement, personnage-environnement) de ce "in" ce que je développe est justement basé sur les interactions, du coup quasiment tous les échanges clients serveurs se baseront sur des requêtes de type "in", ce qui rend la mise à jour de table temporaire à mon sens beaucoup trop lourde (performance, synchronisation, concurrence d'accès) je pense que la table temporaire à son utilité, dans le cas où sa fréquence d'utilisation est assez faible En fait je me posais aussi la question de requête préparée versus requête directe. disons que je construis mon système ainsi : couche DAO (aujourd'hui mes propres classes, demain PDO probablement) couche Factory couche Objet Métier je ne suis pas sûr d'utiliser correctement le terme couche, mais osef en fait ^^ globalement ma couche Factory aurait des classes spécifiques (liste de personnages, liste d'item, etc...) dont le rôle sera - de définir la requête qui va bien pour obtenir les données - de sélectionner pour un enregistrement donné (via son type etc...) la classe qui le portera - de créer l'instance qui va bien en fonction des données rappatriées une classe mère générique (abstraite) avec pour fonction - d'appeler la couche DAO pour lire les enregistrements (et probablement les modifier/créer) - de récuperer les enregistrements et d'appeler la méthode (abstraite) de création d'instance (cf la classe spécifique) et puis diverses autres choses, mais ça donne l'idée tout ça aujourd'hui marche très bien avec ma couche dao personnelle (bon un peu prise du net y a 7 ans mais que je bidouille de temps en temps) mais comme pdo va devenir le standard de php, je préfère reprendre cette partie et exploiter ses possibilités. normalement pas besoin de requête préparée car je ne charge qu'une fois les données (c'est l'objectif de mes couches : ne faire qu'une requête) mais dans une idée un peu plus générique, j'avais pensé " et si à un moment ou un autre, j ai besoin de récupérer une seconde liste d'enregistrement (voire une troisième, etc..)" et c'était là que me semblait pertinent les requêtes préparées avec le "in" J'y vois un intérêt réel pour les update/insert d'objet (car là je ne pourrais la plupart du temps ne faire que des requêtes ne touchant qu'un enregistrement) et un intérêt plus théorique pour le "in" mais bon justement si ça n'existe pas avec le in, pas la peine de creuser plus loin ^^ merci |