Version imprimable
Bonjour,
J'ai essayé de stocker le resultat d'une requête en session afin de l'exploiter par la suite.
Le problème dès je passe à une autre page la variable $result n'existe plus, J'ai déduit que la connexion est fermé dès qu'on passe à une nouvelle page.
Je souhaiterais savoir est-ce bien la cause ? et s'il y a un autre moyen de le faire?
C'est à dire est-ce que je suis obligé de créer une classe dans laquelle je stock tout avant de la stocker en Session ?
Merci
Sans connaitre parfaitement le comportement des focntions mysql*, je pense qu'effectivement un resultat est associé à une connection. Donc qd la connexion est fermée le résultat est libérée.
Après classe ou pas classe c'est toi qui voit. Tu peux très bien l'enregistrer dans un tableau très classique.
Fin ceci dit, qu'est qui t'empeche de requeter, une premiere fois, puis une seconde fois dans la page suivante ?
bye
C'est vrai rien ne m'empêche de lancer la requête plusieurs fois, c'est plus par souci de performance, car je souhaite réduire l'accès à la base de données
comment passe tu la variable à l'autre page (GET ou POST) ??
tu peut stocker l'information que tu veut dans un variable et la passer avec la methode GET...
C'est plutôt dans la Session et je l'a récupère avec $_Session["NomVar"];
utilise les sessions c bien pratique
Hm je ne connait pas le temps d'exection de ta requete mais l'action de serialisation/desrialisation n'à jamais fait l'écho de temps d'execution incroyable.
Pour ce qui est de l'accès à la base de donnée, le plus couteux en temps d'execution amha reste les grosses requetes sur plusieurs tables que l'execution de multiple requetes simple.
A toi de voir.
Le problème c'est qu'on ne peux pas sérializer une ressource donc on est obligé de sérialiser les résultats de la requete pour ensuite les retraiter dans la deuxieme pages.
Ca oblige à traiter deux fois les résultats de la requete, ce n'est pas très optimisé, et comme si j'ai bien compris le but du post est d'optimiser...
Salut
Visiblement, il n'est pas possible de mettre un $result dans une session. C'est en effet logique puisque le $result est lié à une connection, dont l'identifiant est perdu à la fin de chaque script.
Pour ton optimisation, il faut aussi considérer l'utilisation des ressources serveur : si tu mets en cache les tuples de tes requêtes (ce qui semble la meilleure alternative à conserver le $result), tu utilises une grosse quantité de mémoire sur le serveur tant que tu ne détruis pas ta session.
En revanche, si la requête est effectuée de nouveau sur chaque page, tu n'utilises pas cette quantité de mémoire et tu fais confiance à MySQL pour mettre en cache tout seul les requêtes fréquentes et leurs résultats...
C'était ma proposition : ne t'occupe pas de tout ça car MySQL le fait déjà à ta place.
Deplus, .. a quoi sert d'executer un SELECT ( ou une connexion ) si ce n'est pas pour utiliser les resultats ? .. c'est du temps perdu ...
Il suffit de faire la requete au moment ou ton script a besoins des donnees. Pas avant... ca optimise tes acces bases.
Merci à tous
Ca me semble plus claire
Si je puis me permettre une suggestion : Je stockais dans une session le résultat d'une requête pour ensuite pouvoir l'exploiter dans d'autres pages, comme par exemple dans le cas de pagination.
Le problème, et même en étant sur un serveur dédié, c'est que lorsque le fichier de session dépassait 2 Mo, php se mettait à se comporter de façon un peu aléatoire et étrange.
Je suis donc passé aux tables temporaires que permet Mysql, et non seulement je n'ai plus de problème de dépassement de mémoire tampon, mais mes scripts sont un chouille plus rapide.
macbook : Ton témoignage est intéressant (il ne faut jamais oublier les tables MERGE) mais, AMHA, l'exemple est mal choisi. En effet, MySQL dispose de la clause LIMIT, bien plus intéressante que les tables temporaires lorsqu'il s'agit de pagination car elle t'évite de sélectionner des données dont tu ne te servira pas.
C'est vrai, mais dans le cas d'une pagination ma table temporaire ne contient que les éléments issus du premier select.
Sur une table de plusieures centaines de milliers d'enregistrements dont j'extrait une centaine à peine de tupple, une table temporaire pour paginer est plus légère, même si chaque champs du select est indéxé.
Je dis ça, j'ai peut-être tort mais je pense sincèrement que c'est une mauvaise idée que d'utiliser une table temporaire (même MERGE) pour la pagination : tu gaspilles une quantité énorme de mémoire côté serveur et je ne suis pas sûr que aies un contrôle parfait la suppression de la table en question (que se passe-t-il si je ferme le navigateur ?).
De plus, cela suppose que tu fasses un SELECT de davantage de tuples que ceux dont tu as besoin pour la page actuelle, non ?
Bonjour, j'ai un soucis similaire avec une base postgreSQL, passer un $result en session ne fonctionne pas, ce qui est bizzare.
En effet, si je travaille sur unseul script, je peux toujours acceder aux resultats de ma requête à l'aide de $result, même après avoir explicitement fermé la connection à la base (avec pg_close($connection) ).
Si quelqu'un peut éclairer ma lanterne...