Discussion :

[antoineklein]

bonjour à tous.
voici une petite question que je me pose et afin de ne pas faire d'erreur, que je vous pose.
j'ai un site en php et mysql, avec un module d'admin;
dans ce module j'utilise plusieurs tables de la BD afin de pouvoir modifier ou supprimer une ligne, je peut également trier la liste par les entetes.
actuellement que ce soit pour faire la liste, editer le formulaire de modif ou reafficher la liste avec un autre critère de tri, je retape dans la base avec une requete sql pour alimenter une table (array).
ca marche bien mais est-ce judicieux ?
ne faudrait-il pas mieux que j'alimente la table avec une requete sql (que je remettrais à jour lors d'une modif ou d'une suppression) et que je tape que dans la table que je mettrais en variable de session ? ca prendra plus de mémoire mais la rapidité devrais être amélioré ?
qu'en pensez vous ?
qu'est ce qui est le plus pro ?
j'espère avoir été assez claire :-)

[antoineklein]

et bien ca ne se bouscule pas pour répondre sur ce forum.

il y a qqun ?

la question est si débile que ca ?

[antoineklein]

complément d'information

pour donner plus de précision sur le fonctionnement de mon module d'admin (visualisation d'une table):

1) requete de la table
2) stockage du resultat de la requête dans un tableau
3) tri du tableau en fonction de l'entete cliqué
4) affichage du tableau
si je clique sur un autre entre je recommence au 1 alors qu'il me paraitrais plus correcte d'aller au 3.

votre avis ?

ps le tri ne peux se faire lors de l'étape 1 car certaines colonnes sont soumis à calcul, condition, ..

[SQLpro]

Il serait plus judicieux de poser cette question sur le forum MySQL.

A +

[antoineklein]

je ne vois pas en quoi ma question est spécifique à une base de données ? donc le forum général sgbd me semble le plus adapté.
mais bon, vu le nombre de réponse, je ferais peut-être mieux de suivre votre conseil :-)
on va attendre le week-end, il y aura peut-être plus de monde

[SQLpro]

site, php, formulaire, reafficher, variable de session

Sont des mots de ton premier post qui n'on rien à voir avec les SGBDR.

2) stockage du resultat de la requête dans un tableau
3) tri du tableau en fonction de l'entete cliqué
4) affichage du tableau

Sont des notions qui n'ont rien à voir avec les SGBDR.

A +

[antoineklein]

ma question est : "faut-il mieux taper systèmatiquement dans la base de données ou stocké le contenu d'une table de la BD dans un tableau qui devra être mis en variable de session"

c'est pour moi une question plus liée à la base de donnée en général qu'a mysql en particuler.

enfin bon ca ne fait pas avancer le schimilibilique :-)

[orafrance]

la réponse est : ça dépend

Si c'est pour accéder plusieurs fois aux données dans une même session (déjà faut se poser la question de l'intérêt ) alors le tableau sera surement plus intéressant

[antoineklein]

du constructif, merci

les opérations sont liés à l'administration d'un site donc la session reste la même mais la page est rappelé à chaque changement du critère de tri.
le contenu du tableau ne change donc pas, il est juste trié et affiché différement.
et c'est la que le principe de refaire une requete sql pour alimenter le tableau alors que le contenu n'a pas changé me dérange.

[orafrance]

pour un changement de tri je passerais pas un tableau... si la volumétrie n'est pas suffisamment imposante pour risquer de faire ramer l'appli

[antoineklein]

je trouverais ca plus logique comme méthode, mais ca m'oblige à utiliser une variable de cession, pour ne pas perdre ma table au rechargement de la page et on me dit que la variable de session n'est pas du tout faite pour stocker un tableau, on sort un peu du cardre SGDB là :-)

[SQLpro]

La gestion de session s'oppose à la montée en charge et interdit tout changement de contexte d'exécution ce qui signifie que tu ne pourra jamais faire une ferme de serveur avec du load balancing...

Donc éviter les sessions ou bien les gérer soit côté SGBDR (trace) soit côté client (cookie) voire les deux.

Quand au tableau de données c'est effcectievement une bonne solution si les données ne changent pas et si la page montant les données du tableau est partagée. Dans ce cas, il convient d'unifirmiser toutes les tables de réféence pour n'avoir qu'un seul tableau.

A +