Ca fait mal à la tête de lire ce poste après 19h et une longue journée de taf...
Je suis vraiment pas fais pour la prog !

Parce que non(a ET b) = non(a) OU non(b)
De la logique de base.

Les choses qui méritent d'être faites méritent d'être mal faites.

T-oday I bake, to-morrow brew,
the next I'll have the young queen's child.
Ha, glad am I that no one knew
that Rumpelstiltskin I am styled.

Juste une suggestion: avant d'optimiser une requête comme celle-là, il vaudrait mieux la décomposer, y aller par étape, comme un algo en sorte. Et puis comme Nakuni voulait un traitement côté serveur, alors l'algo SQL se transforme naturellement en procédure stockée.
Pour optimiser il faudra nous préciser si c'est en nombre de lignes genre "challenge pour les neurones" car souvent ça débouche sur des requêtes illisibles et inmaintenables, si c'est optimiser le temps de traitement ou l'affichage sur la page ça dépend de tellement de paramètres que le mieux c'est de faire des tests (en général une solution mix code + proc sql).

Bah euh ce matin j'ai du mettre 2h pour en arriver là et ça fait exactement ce que je veux en une requête donc je n'y touche plus tant que je ne vois pas de bug

Pas de soucis. Je soumettais juste l'idée qu'un bon résultat n'est pas synonyme d'une requête juste. Mais si le résultat est juste après tout...

Ahhhhh tu vas me donner mauvaise conscience

Peut-être une petite amélioration qui pourrait être utile pour le futur traitement du curseur dans le code php:
dans le ordre by d'abord trié sur le n° de question en croissant, puis sur le nb en décroissant ?
Si ce site est public une petite url pour voir le rendu ?

Et puis une petite question tu n'as pas d'erreur avec la syntaxe exacte que tu donnes ? Parce que dans le group by on retrouve normalement tous les attributs non agrégats: donc l'intitulé de question et l'intitulé de réponse que tu as ajouté dans la clause SELECT devraient en théorie compléter ton GROUP BY ???

t'es viré

« Lemon est vraiment un Malade... Heureusement qu'il est de notre côté.» (Guzmud)

« Lemon est fort, Lemon est beau, Lemon est sexy, Lemon est omniscient, Lemon est THE Lemon » (Violenconjugal)

« Lemon a un monde à lui dans sa tête » (Im_a_player)

« Putain, ca devient trop ce clan. Bientot on appelera Lemon le Parrain et le clan la Famille. Nawak » (Rumpl)

« Lemon est le seul mec qui préfère qu'on lui dise qu'il a une grosse femme plutôt qu'une grosse bite. » (Thrallscream)

« Lemon vient de me montrer... c'est ENORME !!! » (Seven)

« Lemon est un dieu, et Thrall a une.... enfin bon, je m'égare. » (Titi-fr)

Pourquoi trier d'abord sur le num je comprend pas? J'ai justement besoin d'avoir le nb comme critère de tri car je ne récupère que le premier résultat en fait, j'ai besoin du plus grand nb

Pour le group by pas d'erreur de syntaxe là non.

Pour l'URL, quand ça sera en ligne sans pb, pour le moment c'est un projet top secret que je fais sur mon temps libre au bureau

Elle m'embrouille trop la tête cette requête, déjà j'ai du mal à expliquer le principe du site à mes "beta testeurs" lol

Trier en premier sur le num_quest permet d'obtenir un résultat type:
r.num_quest | r.num_rp | q.int_quest | rp.int_rp | count(*) as nb
1 2 bla bla 15
1 1 bla bla 9
1 3 bla bla 6
2 3 bla bla 37
2 1 bla bla 12
etc... Donc pour l'exploiter c'est rangé par num de question, puis à l'intérieur par réponse qui ont le plus de vote.

Bah ouai mais moi j'ai besoin de ça:

2 3 bla bla 37
1 2 bla bla 15
2 1 bla bla 12
1 1 bla bla 9
1 3 bla bla 6

D'ailleurs j'ai modifié mon ORDER BY comme ça pour gérer les égalités:
ORDER BY nb desc, rand()';