En rapport à la Palmichèvre, je vais dans la liste et demande un classement inversé par nombre de messages...
Et là, impossible de comprendre la cohérence du classement.
C'est pas par pseudo, c'est pas par année d'inscription c'est (du coup) pas par nombre de post ?

Allez, soulager le rationnel qui est en moi :!:

par ce que tu veux... tu as une boite en haut qui te permet de les classer par nombre de post, pseudo, date d'inscription....

Hey, truffe, relis mon post, pour voir !

La liste est classée dans l'ordre décroissant du nombre de posts : quel est le problème ?

Grrrr ca m'énerve quand personne me comprend !

Je cherche le pseudo de Miss Oupsman.
Elle a 0 post. DOnc je classe par nombre de post (message + croissant).

La liste obtenu, elle n'a aucune rationnalité apparente !
Pourquoi machin est avant bidule dans ce classement ?

Lorsque tu classes par post - croissant, il prend d'abord les plus anciens inscrits (en tout cas c'est ce qui me semble ). Donc à l'intérieur du classement par post, en cas d'égalité (comme pour tous les "zéro post"), le prochain classement est la date d'inscription.

Bon, c'est le deuxième critère (implicite) que tu cherches ? Apparemment il n'y en a pas... Ce n'est pas non plus un outil d'analyse très évolué

Voici la requête utilisée pour trier en fonction du nombre de post :

Comme on peut le voir, il n'y a qu'un seul critèrede tri : le nombre de post ou user_posts.

Lorsque la base trouve plusieurs utilisateurs ayant un nombre de psot identique, l'ordre d'appartition de ces utilisateurs se fera selon un pseudo hasard.

8O bizarre quand même !

Au contraire, c'est logique.

Là je pense que tu raisonnes selon les tris des tableurs comme excel qui se "souviennent" des derniers tris demandés.

Avec une base de données, le principe est différent.
Pourquoi voudrais-tu qu'elle fasse un travail qu'on ne lui a pas demandé ?

Ben c'est le côté "pseudo aléatoire" qui me tarabuste...
Vu que le classement est toujours le même, il doit bien exister une règle.
Non ?

Un numéro interne de la base de données (la clé primaire de la table, si elle n'est pas basée sur d'autres champs existants, mais un nombre généré automatiquement, par exemple)?

Ce qui expliquerait que ce sont les membres les plus anciens qui viennent d'abord.

(on n'a vraiment rien d'autre à faire... )

Et non, ce ne sont pas les plus anciens... Donc Vu que le 2002 et le 2004 s'entrecroise...
Quand à un numéro de base de donnée, OK mais pourquoi celui-ci serait-il aléatoire ? Par défaut, une implémentation "+1" me parait plus logique

euh calino, t'es demandé à l'accueil par les monsieurs en blanc

Je ne parle même pas d'une séquence auto-incrémentée mais d'une numéro interne, car dans une base de données, on ne peut jamais garantir où dans une table se fait l'insertion d'un enregistrement. Ce n'est qu'à la visualisation qu'on peut déterminer l'ordre d'affichage.

Si le sujet t'interesse, je peux te pretter quelques jours un petit livre (860 pages) consacrés à MySQL.

Je suis trop loin, je ne t'entend plus !

Je ne vois pas où est le souci, si le programmeur SQL ne spécifie pas de 2ème critère de tri, alors c'est que c'est sans importance, et la base de données peut bien les retourner dans l'ordre qu'elle veut ...

Pour compliquer la chose les serveurs de bases de données, ont des caches où ils cherchent en premier.
Tu peux dire que c'est de l'aléatoire.

Ben pourtant, c'est un bon prétexte de quadripilosécation ...
T'aimes pas ? O:-)

Je ne savais pas que la base de donnée avait son existance propre !
Elle a pensé à bien se couvrir ce matin ?

Elle n'en a pas besoin : la base de données reste au chaud dans son serveur. Elle nous permet juste de la regarder par la fenêtre, sous des angles différents selon son humeur...
Il faut cependant savoir que, d'après Corto, la base a des caches dans son serveur, ce qui explique qu'on peut ne pas la voir (mais moi, ça ne m'est encore jamais arrivé).

Bien sûr ! D'où tu crois que viennent les bugs ??? Evidemment pas des programmeurs !