Bonjours.  
Je voudrais savoir le faite d'avoir une variable de session de 536Ko (Pour l'instant) est une bonne chose sachante qu'une connection correspond a un fichier de session.
est il possible que tous les utilisateurs puisse etre a la meme variable .
En faite j'ai une variable qui possede quasi toute ma base, pour des raison technique mais comme les internautes auront la meme acces au meme info ça ne sert a rien de répeter la meme information donc est il possible que les internautes puisse prendre l'information dans une seul et meme fichier.
MErci

ben ouais, mais pq tu le fous en session ce fichier alors?

non c'est pas un fichier c'est des donnée issu de la base de donnée

ben relis les dans la base au lieu d'avoir des variables de sessions aussi lourdes

Ou alors, tu fais en sorte de les stocker dans un fichier à part, qui sera lu par tous les utilisateurs.

Je crois que je vais passer par là;
je vais essayé de l'écrire via un print_r($array) et je fasi un eval du contenu de ce fichier    

un demi meg par visiteur, je voudrais pas voir la tronche du serveur qui va devoir se palucher ça  

Pourquoi ne pas faire une requête stockée sur le serveur ? Ou bien une table temporaire dédiée dans la base ? Ce sera bien plus propre !

Tu me parle du contenu du resultat de la requette?
 
Car en faite j'ai trouvé un moyen qui consiste a récuperer le contenu de cette grosse variable puis, faire un serialise de cette variable ca va me creer une chaine de caractere, je l'ecrit sur un fichier et chaque internaute lit le contenu de ce fichier et fait un unserialise pour récuperer le format de ma variable.
De cette maniere la contenu de ma variable est toujour stocké en dure dans et est accessible pour chaque internaute.
evidement je vais mettre un peut de sécurité sure l'acces a ce fichier pour pas me faire =>  

le problème, c'est que comme tu le dis, ton fichier risque d'être lisible.
 
mais ça, c'est rien.
 
par contre, lorsque tu vas mettre à jour le fichier, pour peut que des utilisateurs y accèdent, soit c'est le process qui tentera d'écrire dans le fichier qui va planter, soit c'est les utilisateurs quio tentent de le lire. En somme c'est très moyen.
 
Le pire, c'est que le fichier, risque de ne pas toujours être présent (lors de la réactualisation du fichier, tu feras surement un delete puis un create file). A ce moment, si une personne tente de lire le fichier entre ces deux manipulation, elle n'aura pas de fichier dispo. Fait donc très attention que ton process de lecture ne tente pas d'écrire le fichier s'il n'existe pas, car tu risques de très gros ennuis

du coup, la seule vrai solution propre consiste à mettre cette variable dans une table.
 
mettons que ta variable contient le résultat d'une requête complexe, genre affichage de toute l'arborescence d'un catalogue.
 
a ce moment, je te conseille de faire une table très simple :
 
PARAMS
ID
VALUE
 
Avec ID, un string contenant "CATALOG" par exemple
Et VALUE un bigstring (ou blob) contenant le résultat de ta requête.
 
L'avantage en effet des BDD, c'est d'accepter les requêtes concomitentes, ou de mettre en queue celles qui se heurent à un lock. Ainsi, un utilisateur peut reconstruire cette variable tandis que d'autre continuent de lire l'ancienne valeur pendant ce temps.

haa c'est une bonne idée.
Effectivement concernant l'utilisation du fichier il y a un risque. Mais il ya une solution d'installer ce fichier derriere un htacces. Je comptais pas détruire et recréer le fichier mais de vider son contenu et de le remplire tous les 24h pour faire les mises à jours du fichier.
 
Pour stocker le resultat (de ma requette c'est a dire en serialisant ma variable afin de garder ça structure) en base c'est aussi une bonne idée.
Maintenant a savoir qu'elle est le gain en performance entre lire dans une base et lire le contenu du fichier.
 
La je vous demande conseil.

la différence sera infime, que ce soit dans un sens comme dans l'autre.
 
l'avantage, c'est que tu seras moins emmerdé pour la maintenance si c'est dans une base, car c'est fait pour les accès multiples. pas un fichier.

Donc je pense que je vais prendre la solution de la base de donnée!...