Discussion :

[nso.l]

Bonjour,

tout d'abord je tiens à m'excuser si mon langage n'est pas celui d'un pro mais j'ai entrepris il y a quelques mois de m'atteler à la création d'un site personnel d'accès à une BDD qui pourra intéresser "plus d'une poignée de personnes".

J'utilise pour cela PHP & MYSQL et ai déjà créé de nombreux formulaires mais me pose une question de fonds sur le recours aux données de sessions ou aux requêtes.

Pour l'instant j'ai privilégié les requêtes aux données de sessions dans la conception de mes formulaires mais m'interroge par rapport à 3 ou 4 données dont j'ai besoin quasiment à chaque fois. Une requête sollicite le serveur mais une donnée de session aussi. Alors que vaut-il mieux ?

Existe t'il un moyen simple de déterminer à partir de quel moment une donnée de session est préférable à une requête du point de vue de la charge de travail pour le serveur ? J'imagine que c'est fonction du nombre d'utilisateurs etc. mais j'ai aucune idée de la charge que l'un et l'autre peuvent représenter.

En vous remerciant par avance de vos réponses éclairées.

[sabotage]

Attention, les sessions ne sont pas partagées entre les utilisateurs.
Il faudra pour chaque utilisateur, aller chercher la donnée la ou elle est.

[nso.l]

oui ça je sais que les données de sessions ne sont pas partagées (et heureusement pour le coup !).

Il faut imaginer ici plusieurs utilisateurs connectés en mm temps, exploitant simultanément leurs données personnelles.

Alors d'après vous, requêtes à chaque formulaires ou 3 ou 4 données de sessions de plus par utilisateur ? Qu'est ce qui est le + lourd pour le serveur ?

[sabotage]

Si tu as besoin d'utiliser plusieurs fois pendant la visite une donnée provenant de la base sans qu'elle soit mise à jour, alors il vaut mieux la stocker en session.

[nso.l]

c'est ce que je croyais aussi mais j'ai entendu l'inverse récemment et suis un peu perdu (les données de sessions étant soit disant + lourdes pour le serveur qu'une flopée de requêtes supplémentaires à exécuter).

D'autres avis ?

[sabotage]

tu as entendu ça ou ?

[RunCodePhp]

Salut

c'est ce que je croyais aussi mais j'ai entendu l'inverse récemment et suis un peu perdu (les données de sessions étant soit disant + lourdes pour le serveur qu'une flopée de requêtes supplémentaires à exécuter).

J'en suis pas convaincu, je dirais que ça reste à prouver.

Mais il y a un aspect qui n'a pas été évoqué, c'est le coté sécurité, confidentialité des données.
Si on stocke des données trop sensibles, on prend le risque qu'une personne mal intentionné puisse avoir accès à ses données.
L'exemple typique c'est avoir un espace privé donc avec une identification.
Ici, il est théoriquement préférable de ne stocker que son identifiant, tout le reste sera fait avec une requête pour rechercher les autres (nom, prénom, adresse, etc, etc ...).


Après ça, si on remarque que l'on fait trop de requêtes, et que ça amène à des ralentissements, et qu'on en vienne à déporter certaines données dans les sessions pour soulager la Bdd, je ne suis pas convaincu que ce soit une bonne approche, même si au bout ça améliore les performances.
J'ai plutôt tendance à penser que soit il y aurait une optimisation à faire coté Bdd (on peu peut être diminuer certaines requêtes, cache, etc ...), ou alors ce serait la formule de l'hébergement qui ne serait pas adapté au besoin.


En tout cas, de mon coté je ne mets pas de données en session pour soulager la Bdd.
A u niveau des session, je stocke principalement des IDs, des identifiants qui après permettront de récupérer les données associées dans la Bdd.
A savoir aussi qu'il n'est pas rare que les sessions soient elles même gérées dans la Bdd, ce qui est mon cas d'ailleurs.

D'ailleurs, rien n'empêche de se créer une table (ou plusieurs) qui stockerait certaines données récurrentes (persistantes ou presque), et on fera en sorte de récupérer tout ça en 1 seule requête de page en page par exemple.

Il y a à mon sens des solutions pour éviter que les sessions ne soient pas trop "éléments foure tout" (je résume pour faire court).