Afficher requête SQL sur plusieures pages

Bonjour,

Je suis entrain de faire un site web dans lequel j’affiche des données extraites d’une base de donnée MySQL.

Mon problème : lorsque les données a extraire sont supérieures a 5 , je voudrais les répartir sur plusieurs pages sans utiliser les Sessions si possible.

Je vous montre donc un extrait de mon site.

Voici la structure de ma base de donnée :

club (
idclub int(11) NOT NULL PRIMARY KEY auto_increment,
nom varchar(50) NOT NULL default ‘’,
anneeCreation int(11) NOT NULL default ‘0’,
)

Voici le code de mon menu :

<ul>
    <li><a href="index.php?los_angeles">Los Angeles</a></li>
    <li><a href="index.php?new_york">New York</a></li>
    <li><a href="index.php?miami">Miami</a></li>
    <li><a href="index.php?las_vegas">Las Vegas</a></li>
</ul>

Voici une partie de ma page de requêtes SQL :

if( isset( $_REQUEST[‘los_angeles’]) ){
$requete = ‘SELECT * FROM club ORDER BY nom;’;
if($result = mysql_query($requete)) {
echo("

“);
while($ligne = mysql_fetch_array($result)) {
$club = $ligne[‘club’];
$anneeCreation = $ligne[‘anneeCreation’];
echo(”

“);
}
echo(”

$club

Année de création du club : $anneeCreation

");
}
else {
echo ‘Erreur de requête de base de données.’;
}
}

Le nombre de clubs par ville étant élevé, j’aimerais en afficher 5 par pages, avec en lien, en bas de chaque page, le nombre de pages.

J’espère que vous pourrez trouver une solution à mon problème.

Merci.

Tu peux envoyer un argument à ta requête SQL pour n’affiche que les résultats de “1 à 10”, de “10 à 20”, de “20 à 30” etc.

Exemple :


 SELECT *
FROM `club`
LIMIT 0 , 10 

etc. en ayant stocké le nombre de résultats dans une variable que tu incrémente par pas de 10.

privilégie limit x offset y. C’est la même chose, mais ça marche aussi sous pgSQL (bien sûr, faut aussi virer les backtick (`)).
Edité le 12/02/2010 à 16:32

Moi je dis une réponse donnée de vaut jamais la solution trouvé :

www.siteduzero.com…

Voila un exercice qui te faire exactement ce que tu veux faire^^

Exemple sympa Akkai, mais qui utilise aussi “limit” pour tester PHP.
Enfin, dans la pratique ça reste très très lourd… surtout mélanger avec de l’HTML, car rapidement ton code sera impossible à maintenir…

Je te conseille coder ton PHP en MVC : fr.wikipedia.org…

Et d’utiliser un framework, par exemple cake PHP : book.cakephp.org…

exemple :

$data = $this->Article->find('all'); 

Pour afficher du page par page tu à besoin de plusieurs variable :

. Le nombre d’objet par page ( fichier txt ou valeur bdd )
. Le numéro de la page en cours ( variable get / session )
. Le nombre total d’objet

Ensuite c’est assez simple :

  1. Tu compte le nombre d’objet ( ex : 50 )
  2. Tu divise le nombre total d’objet ( 50 ) par le nombre d’objet par page ( ex: 10 ) que tu arrondi à l’entier = 5 pages
  3. Tu récupère la page en cours, et tu fait un calcul pour l’appliquer au limite sql via le nombre de page total ( si page 2 > limite 10, 10 )

Ensuite pour l’affichage des pages en bas, c’est un peu plus complexe, surtout si tu veut faires des boutons suivant / précédent + liste déroulante pour choisir toute les pages. Le truc c’est de faire deux variable $page_suivante / précédante avec chacune une valeur, etc.

Cassage de mythe : Tout les gros site web ( et plein de petit ) utilise des framework web tout fait ( wordpress / joomla ) et je peut t’assurer que le code est lourd, très lourd. Bien plus lourd qu’une petit calcul d’affichage page page codé à la main, même si un peu bancal.

Bon Après tu peut bencher le serveur, mais même avec un calcul de ce type et 200-300 objet à traiter c’est presque instantané en terme de serveur. Et si tu veut accélérer les calculs, comme celui du nombre total de pages ( sql count ), tu peut très bien stocker la valeur dans un fichier texte ou dans la base de données à chaque fois que tu ajoute un objet.

Un “gros site web” ne passe pas son temps à exécuter des requêtes SQL pour paginer des listes de villes. Quant à l’utilisation de Joomla et wordpress (moteur de blog), …

Paginer directement avec du SQL crée un overhead très fort sur et ton réseau, et ton SGBD. Cette solution est couramment utilisée, mais aussi parce que la charge requise est relativement faible.

Et en pratique, comment ça se passe sans utiliser les options SQL (limit, row_number() etc) ? (j’ai bien une idée, mais n’ayant jamais réellement fait autrement…)

De ce que j’en ai vu :

  • les listes qui n’évoluent pas sont écrites en “dur” ou chargées une seule fois en mémoire
  • les listes paginées sont cachées soit au niveau session, soit au niveau application (= tous les utilisateurs), par le biais d’un ORM par exemple

Ces solutions surchargent l’occupation mémoire, mais déchargent le CPU et le réseau. Pas besoin d’être un grand analyste pour voir que l’occupation mémoire vaut vraiment le coup lorsque la surcharge ne dépend pas ou très peu du nombre de sessions.

S’agit pas de dire que ces solutions prévalent sur tout et n’importe quoi. D’ailleurs, il doit surement exister des solutions encore meilleures (issues du cloud computing notamment). Mais il me parait important de ne pas présager d’une solution sur une autre, quelque soit les circonstances.

Malheureusement si :confused: Sql est quand même loin d’etre un truc très lent. et comme je l’ai dit c’est qu’une solution parmis tant d’autre. Si pas de variable “exotique” il peut utiliser un système de cache dans le panneau d’administration !

Dans ce cas, j’aimerais que tu cites tes références pour pleinement apprécier ton point de vue.

Attention, je ne suis pas en train de dire qu’un SGBD, c’est mal.