Reprise du message précédent :
non. Car plus vite l'ordonnanceur sait ce qu'il doit retourner au final, moins il conservera de données inutiles.

(c'était pas une vraie question, en fait.)

Et je dois utilié quoi alors à la place ?
 

 
Tu m'as proposé ça pour conter les messages, ça fonctionne ?
Parceque je n'ai null part une variable id_message, c'est une variable stantard qui réfère au id ?

 
je me disais bien

 
non serieux. Fais un peu de lecture. id_message c'est le nom du champs correspondant aux id de tes messages. Je ne sais pas comment il s'appelle le tien. Il te suffit de remplacer  

Mais heu, moi je savais pas.
 
Tu aurais du mettre id_dumessagecible, ou un truc comme ça bien lourd, comme ça je vois direct que c'est pas une variable "standard" de mysql.
 
En tout cas merci pour l'aide.

Mais sur ton "sommaire" tu listes tous les messages ou pas? T'as qu'une page en gros? Tu compte n'en avoir qu'une?
Ca simplifie mais de toutes manière quand tu parcours ton tableau de résultats pour afficher le sommaire tu peux très bien compter les messages Donc tu sais combien t'en a avant (n-1) et le nombre total Donc je vois pas le soucis
 
Après si tu pagine le "sommaire" faut juster compter l'ensemble et le garder sous le coude quelque part.
 
Après pour la meilleure méthode en fonction du nombre faut tester et chronométrer Puis le cache il sert à quelque chose La différence est impressionnante et par défaut bizarrement il est pas activé de mes souvenirs

Oui j'ai une pagination avec le sommaire.
En fait je recalcule tout l'ensemble à chaque fois, que se soit dans le sommaire ou dans l'affichage des blogs.
 
C'est simple à utiliser le cache ?

Quand je dit cahche je parle du cache du SGBD (système de gestion de bd) et ça permet de gagner du temps sur les SELECT si la requête est en cache
 
Maintenant les updates faut les faire...
 

Mouai, je me renseignerai la dessus.
 
Sinon j'ai désactivé l'incrémentation auto de l'id (pour la faire manuellement), parceque avec la décrémentation après suppression d'un post, l'incrémentation auto n'est plus continue.
 
Je sais c'est une dictature sur l'id que je fais, pas biennnnn.

Siron > Personellement, avec mysql, j'utilise un

et ca marche trés bien même s'il y a des trous, et ca me permet de garder l'autoincrément. (on lui indique combien en sauter et combien on en veut)
 
 
Avec acces, c'est un truc du genre

Je me rapelle plus si le TOP est juste aprés le SELECT ou juste avant le FROM. En tout cas, ca marche tout aussi bien à par qu'il faut sauter les (numerodepage-1)*nbpostparpage premier résultat retourné vu qu'ils ne font pas parti de la page courante. (on lui indique combien on en veut en comptant ceux qu'on veut sauter)
 
 
Avec postgressql c'est

ce qui revient exactement au même qu'avec mysql (on lui indique combien on en veut et combien en sauter)
 
Dans tous les cas, ca me permet d'utiliser les autoincrément et je touche jamais à la colone qui correspond vu que même s'il y a des trous, c'est invisible au niveau du code.
 
En fait, il ne faut pas réfléchir en (par exemple) "page 1 = posts numéro 1 à 25, page 2 = posts numéro 26 à 50 ..." mais en "page 1 = 25 premiers résultats de la requette, page 2 = 25 premiers résultats situé aprés les 25 premiers, page 3 = 25 premiers résultats aprés les 50 premiers (25 premiers aprés les numerodepage-1 * 25). Et en réfléchissant comme ça, on peut enfin laisser la base de données calculer qui sont les n premiers et en fait, lui laisser carément nous dire dans quel ordre sont les différents messages.
Tout ça pour dire que si t'arrives à réfléchir différement au probléme, alors tu n'auras plus à toucher à l'autoincrément et entre nous, ne pas l'utiliser pour éviter des trous d'id, c'est vraiment chercher des complications par la suite.
Par exemple, avec un indice manuel, comment tu feras quand tu devras censurer un message? Tu seras obligé de le suprimer définitivement ou de le stocker dans une table à part (ca rajoute des étapes) pour le stocker le temps de voir si c'est une censure définitive. Et si tu les suprimes, et qu'un jour tu te plante de message par ce que t'étais creuvé, tu vas faire comment pour recréer la super réponse pondus par un autre vu que t'as plus le texte du message nulle part?
Et si jamais des intervenants de ton forum veulent la possibilité de ne plus voir s'afficher les messages d'un gas qu'ils ont appris à détester, tu vas faire quoi? Tu vas leur répondre "a ben non, ca je peux pas faire par ce que ca fera des trous dans l'affichage!" ?
Quand à l'index que tu calcule à la main, si ton forum devient fréquenté (ce que je te souhaite), tu risques de te retrouver avec deux emssages qui auront le même index vu que tôt ou tard, une personne postera un message pendant que ton script traitera la réponse de la personne précédante (l'index n'étant pas encore incrémenté dans la base de donnée, le suivant essaiera de reprendre le même) ce qui veut complication du code pour gérer ce genre de cas tandisqu'avec un index autoincrémenté, c'est la base de donnée qui s'occupera de se genre de cas et elle elle s'en sortira toujours.
 
En bref, mieux vaut avoir un id dont certain numéro n'existent pas et laisser la base de donnée tout nous fournir comme il faut sur un plateau qu'un systéme à indice manuel nécessitant une grosse gestion d'erreur et qu'on ne poura jamais faire évoluer que difficilement car les évolutions entraineraient beaucoup de complication.

Omega2, je prend note de ta méthode, mais je ne crois pas l'utilisé pour se projet, du moins pas pour le moment (en fait j'en ai marre de travailler sur cette pagination).
 
En fait c'est un blog pas un forum, donc ça réduit pas mal les cas qu'il faut envisager, j'ai juste comme fonction sur les posts :
 
-créer
-modifier
-supprimer
 
Mais je garde ton algorithme à porté de main pour peut-être un projet plus ambitieux (ou simplement une futur rationnalisation et restructuration de mon blog).
 
Encore merci pour les aides.

Attention en utilisant des LIMIT (et même de façon générale), si vous voulez réellement avoir des données triées, il faut absolument faire un ORDER BY (ne jamais se baser sur le fonctionnement interne d'un SGBD qui fait qu'à un moment donné, les données sont renvoyées triées même si on n'a pas mis d'ORDER BY).
 
De toute façon, si le parcours des données fait qu'elles sont triées par défaut, le SGBD ne va rien faire de plus ...