PAGINATION JAVASCRIPT PHP MYSQL
spipod
Messages postés
23
Date d'inscription
mercredi 2 février 2005
Statut
Membre
Dernière intervention
17 juillet 2009
-
6 juil. 2011 à 10:33
poston - 3 mars 2013 à 16:27
poston - 3 mars 2013 à 16:27
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/53357-pagination-javascript-php-mysql
https://codes-sources.commentcamarche.net/source/53357-pagination-javascript-php-mysql
3 mars 2013 à 16:27
Script 2011..nous sommes en 2013..:)
Je suis un débutant et j'aimerai utiliser ce script avec les pages de détail. Seulement, je ne sais comment faire. Un peu d'orientation? Merci..
13 juil. 2011 à 17:23
J'ai juste modifié le source donné pour que l'on voit comme quoi l'idée est simple. Mais ce n'est pas l'aboutissement auquel je suis arrivé. c'est juste l'avant goût, l'idée d'où je suis parti car je continue à creuser puisqu'au niveau des chronos, il n'y a pas photo.
Actuellement, je suis plutôt sur un modèle CMS avec gestion des affichages de tables directement stockés dans la BDD. La requette passe par une procédure stockée qui à partir d'un résultat et d'un gabari nous ressort une table toute construite avec, s'il le faut, des liens dynamiques pour éditer un profil si le statut est éditable (pour reprendre ton exemple). Du coup avec la procédure stockée, celà rentre dans tes principes de séparation des languages.
Le plus compliqué étant de mettre en place un gabari modulable par backoffice.
Voilà, peut-être un jour je publierai mon source si j'aboutis à quelque chose de convainquant.
13 juil. 2011 à 10:57
Tu as certainement raison.
Je n'ai pas pris le temps de tester l'exemple que tu proposes mais, cette méthode sera très complexe à gérer si il y a des divergences par enregistrement (user).
Je parle de l'HTML qui pourrais être +/- conséquent par enregistrement.
Exemple:
--------
Dans un backoffice, je pourrais avoir une liste avec certaine personne qui serait RO (uniquement en lecture) ou RW (lecture et éditable).
Donc, si l'utilisateur à un statut éditable, dans la liste, il y aura un lien "éditer".
Ta méthode serait trop complexe à gérer.
De plus, c'est régresser dans la méthode de coder.
Pour ma part, séparé les langages pour une meilleur gestion est conseillé.
12 juil. 2011 à 18:56
PHP est très mauvais comme itérateur. Pour un traitement de +eurs milliers de références, une page pourrait demander beaucoup de temps à s'afficher alors que la requette n'aura demandé que quelques millième de secondes.
Une méthode que j'ai commencé à implémenter et qui demande encore de l'amélioration, c'est d'utiliser mysql pour construire le tableau. Ce qui fait qu'au lieu de faire ceci:
4.$sql="select * from mytable";
5.$q=mysql_query($sql);
6.$show='';
7.while($r=mysql_fetch_array($q)){
8.// id nom prenom telephone email adresse ville codepostal region pays date commentaire
9.$show .= '<tr><td>'.$r['nom'].' - '.$r['prenom'].' - '.$r['telephone'].'</td><td>["pagedetail.php?id='.$r['id'].' '.$r['id'].']</td><td>'.$r['email'].'</td></tr>';
10.}
On a ceci:
4.$sql="select concat("<tr><td>",`nom`," - ",`prenom`," - ",`telephone`,"</td><td><td>",`email`,"</td></tr>") as show from mytable";
5.$q=mysql_query($sql);
6.$show='';
7.while($r=mysql_fetch_array($q)){
8.// id nom prenom telephone email adresse ville codepostal region pays date commentaire
9.$show .= $r['show';
10.}
Ce qui ne semble pas changer grand chose mais qui en fait permet un gain de performance considérable sur de grands résultats
Voila, c'est tout
11 juil. 2011 à 13:45
9 juil. 2011 à 10:32
Dans mon premier post, j'explique que le LIMIT ne récupère aucuns champs indexés sur la table.
Donc, le LIMIT parcourt toute la table.
Tu pourras constater qu'avec le BETWEEN, la totalité de la table n'a pas été parcourue avec l'indexation.
Pour comprendre ce qu'il en retourne, l'optimisation d'une requête SQL ce vérifie avec un EXLAIN.
http://dev.mysql.com/doc/refman/5.0/fr/explain.html
7 juil. 2011 à 16:42
@stay en effet pour plus de sécurité vu que desfois les débutants font des copier coller bête et méchant il faudrait limiter le nombre de retour donc comme tu le préconises la requête sql devrait être raisonable
$sql="select * from mytable limit 200"; par exemple
a++
7 juil. 2011 à 16:00
En suite @cod57, tu aurais pu préciser au départ à quel projet était destiné ce code.
Le problème chez un débutant, c'est que ce code aurait pu servir pour tous types de projets.
Donc, merci pour moi également.
--------------
Attention, sur certains sites web sur lesquels j'ai bossé, l'optimisation du code était lié aux travail mal pensé au départ.
Cela évite des frais supplémentaires aux clients et aucune justification.
--------------
PS : ne partez jamais sur un code facile ou sur une idée fondée chez un débutant.
Car, c'est une perte de temps.
Pour moi la meilleur méthode d'apprendre la syntaxe ou la logique d'un langage, c'est de passé par un livre.
Je crois que ce forum était destiné à l'optimisation du code et pas "voici du code et fait en ce que tu veux".
Il y a des tutoriels sur le web pour ça !
6 juil. 2011 à 14:04
6 juil. 2011 à 11:16
Mais pour moi, petite table ou grande table, c'est du pareil au même.
La réactualisation du code html restera toujours aussi simple.
Un petit peu d'Ajax devra être utilisé.
6 juil. 2011 à 11:04
Je crois que tu t'égares un peu, le but de ce code permet d'éviter les ré-actualisations HTML d'une façon très simple pour ne pas solliciter le serveur PHP pour de la pagination.
Le débutant avec sa petite table d'une centaine d'enregistrement y trouvera son compte.
Cela dit, ta remarque peut être utile pour quelques lecteurs qui recherche plus d'actualisation entre utilisateurs, puisque dans ton exemple, les insertions dans la table seront pris en compte, alors que dans le source cité, les nouveaux enregistrements d'un autre utilisateur ne seront pas visible sans le F5.
6 juil. 2011 à 10:43
Tu montres bien, ta maitrise en JavaScript.
Mais, imaginons que dans cette même table, il y aurait 150000 membres.
Cela veut dire que tu vas récupérer la totalité des membres pour ensuite les parsers en JavaScript.
Je crois qu'on peut optimiser cela si l'on modifie ta requête SQL.
Tu as indexé correctement le champ id, parfait.
Je déconseille à tout le monde d'utiliser la clause LIMIT (souvent utilisé pour la pagination sur les forums), car elle ne se préoccupe pas de l'indexation.
Un BETWEEN sur le champ indexer serait plus judicieux.
Mais, il y a aussi un inconvénient.
Si un enregistrement est supprimer entre, exemple : BETWEEN 80 AND 100, 19 enregistrement sera retourné et non 20.
Voici le résultat après un EXPLAIN sur cette requête :
EXPLAIN SELECT * FROM `mytable` WHERE id BETWEEN 10 AND 20
id select_type table type possible_keys key key_len ref rows Extra
-------------------------------------------------------------------------------------------------------------------
1 SIMPLE mytable range PRIMARY PRIMARY 3 NULL 11 Using where
Voici le résultat après un EXPLAIN sur ces deux requetes :
EXPLAIN SELECT * FROM `mytable` ou EXPLAIN SELECT * FROM `mytable` LIMIT 10,20
id select_type table type possible_keys key key_len ref rows Extra
-------------------------------------------------------------------------------------------------------------
1 SIMPLE mytable ALL NULL NULL NULL NULL 100
--------------
Donc, tu peux constater que la totalité de la table n'a pas été parcouru avec l'indexation.
Bien sûr, tu devras faire une modification par la suite dans le JavaScript pour la pagination et tu ne devras plus parsers tous les enregistrements.
6 juil. 2011 à 10:33
Perso, j'aurai imposé le style display none par défaut (par style ou class) sur chaque ligne de tableau, puis utilisez un var 'page_actuelle' pour ne pas modifier chaque ligne de tableau dans la fonction selectPage : display_none sur page_actuelle, puis display table-row sur la page demandée.
Cela juste pour aller un peu plus vite dans la pagination.
Mais ... cela ne change rien à mon appréciation.