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).

[nso.l]

tu as entendu ça ou ?

un enseignant qui m'aide dans mon projet.

Mais je cherche simplement à comprendre exactement comment cela marche parce que j'ai 2 ou 3 requetes qui reviennent quasiment à chaque formulaire et j'aime bien comprendre les choses.

Il doit y avoir un point d'équilibre où la charge de travail liée au traitement des requêtes excède celle liée à l'exploitation des données de sessions.

Il y a de la doc sur ces questions ?


@RunCodePHP

Merci pour cette réponse. Effectivement la question de sécurité dans mon projet est à un niveau très élevé. C'est peut-être la raison principale indépendamment de la charge serveur.

L'idée de rassembler en 1 table les données les plus fréquemment employées est par ailleurs excellente. Merci !

Juste pour revenir sur cette histoire de sécurité attachée aux données de sessions.

Est ce que vous pouvez être + précis sur les risques encourus. Car plusieurs des données que je récupère sont juste binaires (0 ou 1). Elles me permettent entre autre, de qualifier mon interlocuteur et d'adapter le site à ses préférences. Quel risque j'aurais à mettre en données de sessions des 0 ou des 1 ? Serait ce une porte ouverte sur d'autres choses ?

[sabotage]

Il doit y avoir un point d'équilibre où la charge de travail liée au traitement des requêtes excède celle liée à l'exploitation des données de sessions.

Je ne vois vraiment pas les choses comme ça.
Pour que les sessions soient moins avantageuses, il faudrait qu'a un moment, le système de fichier soit ralentis par un nombre important de fichiers de sessions.
Sinon une lecture simple d'un fichier est plus rapide que connexion + requete + exploitation du resultat à tout point de vue.

[Snooky68]

Bonjour à tous,

Je me permet de donnée mon avis...
Et je suis d'accord avec RunCodePhp! Pour moi les sessions ne sont en aucun cas une technique de "sauvegarde" des données! Je ne place que des id en session! Le session permet de garder ... une session pour l'utilisateur, et non des données!

Ensuite je fait des requêtes, même si elle sont récurrente! Se qu'il faut c'est que tes bases de données soit bien faite et rapide! Personnellement, même avec des requêtes sur des tables de million d'enregistrement j'ai des bon résultat! Parfois jusqu'à 100 requête pour une seul page traité en quelque centième de seconde!

Après se que j'ai souvent vus pour des personnes qui débute, c'est des requêtes "identique" et des duplications en base!

Par exemple, au début je cherche l'utilisateur pour savoir s'il a les droits sur une page, puis sont nom et sont prénom pour l'afficher dans le top du site, et enfin sont adresse qui figure parfois dans le contenu! C'est a dire trois requêtes et trois parcours d'une seul base pour récupérer un seul enregistrement! A évité!

Bref... pour résumer, peut importe le nombre de requête... optimiser la base!!

Voilà... mon avis... @+

[sabotage]

Pourquoi chercher le nom et le prénom de l'utilisateur a chaque page ?