SQL pour recueillir des données à partir d'une table pendant le dépouillement des enregistrements d'une autre
J'ai une table des utilisateurs et des chansons de table, je veux sélectionner tous les utilisateurs dans la table des utilisateurs tout en comptant le nombre de chansons qu'ils ont dans les chansons de table. J'ai cette SQL, mais ça ne fonctionne pas, quelqu'un peut-il repérer ce que je fais mal?
SELECT jos_mfs_users.*, COUNT(jos_mfs_songs.id) as song_count
FROM jos_mfs_users
INNER JOIN jos_mfs_songs
ON jos_mfs_songs.artist=jos_mfs_users.id
Aide est très appréciée. Merci!
En quoi n'est-il pas de travail? Donne-t-il une erreur, ou tout simplement des résultats inattendus?
Je devine la chanson comte est de 1 pour chaque enregistrement.
Je devine la chanson comte est de 1 pour chaque enregistrement.
OriginalL'auteur Wasim | 2011-07-06
Vous devez vous connecter pour publier un commentaire.
La jointure interne ne fonctionne pas, car il rejoint chaque ligne correspondante dans les chansons de table avec la table des utilisateurs.
Utilisation
HAVING
à comparer à un total comme unCOUNT
Vous pouvez ajouter l' (SELECT COUNT()...) de la clause d'OÙ rapport. Je vais éditer pour montrer que. Vous pouvez essayer de les "avoir" de la clause.
SELECT A.*, (SELECT COUNT(*) FROM B WHERE B.a_id = A.id) AS TOT FROM A
est beaucoup plus simple soluitonOriginalL'auteur Narnian
Il y a un
GROUP BY
clause manquant, par exempleSi vous souhaitez ajouter plusieurs colonnes de
jos_mfs_users
dans la liste de sélection, vous devez les ajouter dans laGROUP BY
clause.GROUP BY
et la suppression de la*
OriginalL'auteur phlogratos
Changements:
Ne pas faire
SELECT *
...spécifier vos champs. J'ai inclus l'ID et le NOM, vous pouvez ajouter plus que nécessaire, mais les mettre dans leGROUP BY
ainsiChangé pour un
LEFT JOIN
-INNER JOIN
ne vais pas lister tous les utilisateurs qui n'ont pas de chansonsAjouté le
GROUP BY
de sorte qu'il donne un nombre valide et n'est valable syntaxeOriginalL'auteur JNK
Essayer
OriginalL'auteur christopher_b
Cela semble être une relation plusieurs-à-plusieurs. Par cela je veux dire qu'il ressemble comme il peut y avoir plusieurs enregistrements dans la table des utilisateurs pour chaque utilisateur, un de chaque chanson qu'ils ont.
J'aurais trois tables.
Les utilisateurs, qui a un dossier pour chaque utilisateur
De chansons, qui a un enregistrement pour chaque chanson
USER_SONGS, qui a un dossier pour chaque utilisateur/chanson combinaison
Maintenant, vous pouvez faire un nombre de chansons à chaque utilisateur a en faisant une requête sur la table intermédiaire. Vous pouvez également savoir combien d'utilisateurs ont une chanson en particulier.
Cela vous indique le nombre de chansons à chaque utilisateur a
Cela vous indique combien d'utilisateurs chaque chanson a
Je suis sûr que vous aurez besoin d'ajuster ce pour vos besoins, mais il peut vous donner le type de résultats que vous recherchez.
Vous pouvez aussi vous joindre à l'une de ces requêtes pour les deux autres tables pour trouver le nom d'utilisateur et/ou le nom de l'artiste.
HTH
Harv Sather
ps je ne suis pas sûr si vous êtes à la recherche pour le compte de la chanson ou de l'artiste qui compte.
OriginalL'auteur Harv
Vous avez besoin d'un
GROUP BY
clause d'utiliser des fonctions d'agrégation (commeCOUNT()
, par exemple)Donc, en supposant que
jos_mfs_users.id
est une clé primaire, quelque chose comme ceci:Avis que
COUNT()
est le nombre de lignes qui sont regroupées (dans ce cas, le nombre de résultats par l'utilisateur)SELECT *
etGROUP BY
sur un seul champ, il va obtenir des enregistrements aléatoires parusers.id
, si son moteur SQL permet même (la plupart ne veut pas)Comment ce retour enregistrements aléatoires? Pour chaque ligne de résultat regroupés par jos_mfs_users.id, tous les champs de jos_mfs_users sera le même! Et pas de champs de jos_mfs_songs sont
SELECT
ed (il n'y a qu'unCOUNT()
). Je pense que vous vous êtes trompé!Vous êtes à la en SUPPOSANT que tous les autres champs seront les mêmes. L'OP n'a pas indiquer que c'était un champ unique ou PK. la Sélection des champs n'est pas dans votre
GROUP BY
ou dans une agrégation est un anti-modèle à éviter. Période.Ok, vous avez raison. J'ai édité la réponse à l'état de mon hypothèse.
OriginalL'auteur edam