13-06-2014, 12:16 PM
La requête d'Arnadus est plus proche du langage naturel (problème exprimé en français): le SGDB risque de parcourir une fois la table des réponses, de grouper par catégorie, et d'exécuter 12 fois la sous-requête entre les parenthèses.
La mienne est plus ensembliste: le SGDB devrait parcourir une fois la table des réponses, grouper par catégorie et prendre l'id max, puis faire la jointure avec la table des réponses.
Donc dans le premier cas, on risque d'avoir (1+12*1) soit 13 parcours de la table de réponses (mais je n'ai pas tenu compte du order by ni du limit 1), dans le second cas, on ne devrait avoir que (1+1) soit 2 parcours de la table des réponses.
A vérifier, mais la requête d'Arnadus risque d'être plus longue quand le nombre de messages (ou de catégories) augmentera.
S'il y a des trous (catégories vides), tu peux initialiser le tableau, donc lancer une requête pour récupérer la liste des catégories, initialiser ton tableau PHP en indiquant que chaque catégorie est vide, puis exécuter la requête pour récupérer le dernier posteur de chaque catégorie et modifier le tableau PHP en conséquence.
La mienne est plus ensembliste: le SGDB devrait parcourir une fois la table des réponses, grouper par catégorie et prendre l'id max, puis faire la jointure avec la table des réponses.
Donc dans le premier cas, on risque d'avoir (1+12*1) soit 13 parcours de la table de réponses (mais je n'ai pas tenu compte du order by ni du limit 1), dans le second cas, on ne devrait avoir que (1+1) soit 2 parcours de la table des réponses.
A vérifier, mais la requête d'Arnadus risque d'être plus longue quand le nombre de messages (ou de catégories) augmentera.
S'il y a des trous (catégories vides), tu peux initialiser le tableau, donc lancer une requête pour récupérer la liste des catégories, initialiser ton tableau PHP en indiquant que chaque catégorie est vide, puis exécuter la requête pour récupérer le dernier posteur de chaque catégorie et modifier le tableau PHP en conséquence.