Salut à tous !

J'ai un tout petit souci rapide à régler (a priori), mais je n'ai pas trouvé la solution malgré mes recherches.

Ma table "blog" contient plusieurs entrées, avec un champ "rédacteur".
Il y a plusieurs rédacteurs, et il se trouve que chaque rédacteur peut avoir écrit (et donc entré dans la table) plusieurs articles (entrées).

Ce que je veux, c'est juste afficher les noms de tous les rédacteurs.

Ma requête (toute simple):

'SELECT redacteur FROM blog WHERE publie=true ORDER BY redacteur DESC'

Sauf qu'actuellement, si Rédacteur1 a écrit 3 articles, Rédacteur2 en a écrit 2 et Rédacteur 3 en a écrit 1, j'ai :
Rédacteur1
Rédacteur1
Rédacteur1
Rédacteur2
Rédacteur2
Rédacteur3

Comment je fais dans ma requête SQL (ou php ?) pour avoir :
Rédacteur1
Rédacteur2
Rédacteur3

?

Tu vas utiliser group by.

'SELECT redacteur FROM blog WHERE publie=true GROUP BY redacteur ORDER BY redacteur DESC'

EDIT : Généralement on préfère les champ id (numérique donc) en clef étrangère, les libellés c'est moyen.

Non, GROUP BY n'est pas du tout la bonne solution. GROUP BY s'utilise conjointement avec une fonction d'agrégat, il n'y a aucun intérêt à l'utiliser pour supprimer les doublons. C'est le travail de SELECT DISTINCT :

SELECT DISTINCT redacteur 
FROM blog 
WHERE publie=true 
ORDER BY redacteur DESC;

Merci !

Citation : Fayden

Non, GROUP BY n'est pas du tout la bonne solution. GROUP BY s'utilise conjointement avec une fonction d'agrégat, il n'y a aucun intérêt à l'utiliser pour supprimer les doublons. C'est le travail de SELECT DISTINCT

Le group by va être intéressant si l'on souhaite ne pas doublonner les lignes d'une autre table.

Le distinct va, lui, supprimer purement et simplement les doublons de la valeur du champ donné.
Dans ce cas ça fonctionne mais dans d'autre cas ce sera une source d'erreur si le champ n'a pas la propriété UNIQUE.

Citation : loacast

Le group by va être intéressant si l'on souhaite ne pas doublonner les lignes d'une autre table.

Hum, je suis pas sûr de te suivre. GROUP BY ne sert jamais à supprimer les doublons. Il sert à grouper les données pour utiliser des fonctions d'agrégat sur ces petits groupes. C'est tout.

Citation : loacast

Le distinct va, lui, supprimer purement et simplement les doublons de la valeur du champ donné.

C'est exactement ce que veut l'auteur.

Citation : loacast

Dans ce cas ça fonctionne mais dans d'autre cas ce sera une source d'erreur si le champ n'a pas la propriété UNIQUE.

???
Je ne vois pas ce que ça vient faire dans cette histoire.

Citation : Fayden

???
Je ne vois pas ce que ça vient faire dans cette histoire.

Tu trouves normal toi que l'on trouve un champ libelle redacteur dans une autre table que rédacteur ?
Tu trouves par ailleurs normal de donner des solutions qui vont dans d'autres cas similaires apporter des erreurs ?

Citation : Fayden

Hum, je suis pas sûr de te suivre. GROUP BY ne sert jamais à supprimer les doublons. Il sert à grouper les données pour utiliser des fonctions d'agrégat sur ces petits groupes. C'est tout.

Le group by ne sert justement pas qu'à ça. Il va aussi, et c'est la cas ici, regrouper des lignes sur un critère unique.
Dans ce cas c'est sur rédacteur, mais je me répète, c'est id_redacteur qui devrait se trouver dans cette table.

Citation : Fayden

C'est exactement ce que veut l'auteur.

group by répond exactement à la question de l'auteur.

Tu as mal compris à quoi servait GROUP BY, tout simplement. Ça ne sert pas à dédoublonner quoi que ce soit. Ce n'est pas parce que ça marche que c'est une bonne pratique. Il n'y a aucun intérêt ici à utiliser GROUP BY plutôt que DISTINCT. On utilise GROUP BY conjointement avec des fonctions d'agrégat, c'est tout. Il n'y a pas d'autres cas où l'utilisation de GROUP BY est appropriée.

Après, concernant la normalisation des données, je suis tout à fait d'accord avec toi, mais je ne vois pas le rapport avec son problème. Ce serait la même chose avec des id, il faudrait utiliser DISTINCT pour supprimer les id doublons. Et non GROUP BY.

Citation : Fayden

Il n'y a aucun intérêt ici à utiliser GROUP BY plutôt que DISTINCT.

L'inverse est vrai aussi.

Citation : Fayden

Après, concernant la normalisation des données, je suis tout à fait d'accord avec toi, mais je ne vois pas le rapport avec son problème. Ce serait la même chose avec des id, il faudrait utiliser DISTINCT pour supprimer les id doublons. Et non GROUP BY.

Je viens de faire une série de tests, je pensais que group by mettrais en évidence des erreurs que distinct cacherait tout simplement, mais non.

Il se trouve que distinct et group by ont donnés à chaque fois le même résultat, quelque soit la requête.

Citation : Fayden

Ce n'est pas parce que ça marche que c'est une bonne pratique.

Je ne vois pas en quoi utiliser GROUP BY est une mauvaise pratique ?
Mais je suis ouvert à l'argumentation.

Le problème est que tu confonds deux concepts différents parce qu'ils donnent le même résultat. Je me répète : ce n'est pas parce que ça marche que c'est bien.

Prenons d'abord SELECT DISTINCT. Le nom est très explicite. Dans tous les n-uplets retournés par la requête, prendre un seul exemplaire de chacun parce qu'on ne veut pas de doublons. Donc, si on a les n-uplets (1,2), (2,1), (1,3) et (1,2), un SELECT DISTINCT ne prendrait que (1,2), (2,1) et (1,3). C'est exactement ce que l'auteur veut et c'est pourquoi DISTINCT répond à ce problème.

GROUP BY, en revanche, groupe tous les n-uplets identiques en vue d'appliquer une fonction sur chacun de ses groupes. Rien de plus, rien de moins. Si on reprend les mêmes n-uplets :
(1,2), (2,1), (1,2), (1,3)
Et si on veut calculer le nombre de tuples pour chaque groupe différent, le résultat serait évidemment
(1,2), 2
(2,1), 1
(1,3), 1

C'est ça, GROUP BY. Pas un outil qui supprime les doublons, il n'y a aucune raison à l'utiliser, DISTINCT est déjà là pour ça. Ce n'est pas parce que ça fonctionne que c'est une bonne pratique (et ça ne veut pas dire que GROUP BY est une mauvaise pratique en tant que tel, bien au contraire).

J'ai fait un tour sur des forums anglais dont un m'a redirigé sur un article simple clair et qui, à mon grand dam , semble te donner raison

http://blog.sqlauthority.com/2007/03/2 [...] -vs-group-by/

Que dire à part arf