Requete SQL - count dans un left join

Bonjour à tous

Alors apres de longues recherches cet après midi, j'ai un souci dans une de mes requêtes. (j'ai beaucoup cherché, sans trop savoir où chercher, donc je m'en remets à vos compétences 8-) )

Voila la structure basique de mes tables :

table1(id_table1, var_table1)
inter(#id_table1, #id_table2)
table2(id_table2, var_table2)

Et voici ma requête, assez basique :

Code:

---

1 2 3 4

SELECT id_table1, var_table1, id_table2, var_table2 FROM table1 LEFT JOIN inter USING ( id_table1 ) LEFT JOIN table2 USING ( id_table2 )

---

Jusque là, rien d'insurmontable, ca me retourne :

http://img214.imageshack.us/img214/9752/sanstitrepb.png

Maintenant voila mon probleme : j'aimerais avoir une colonne supplémentaire qui compte le nombre d'occurrences d'id1 pour chaque ligne. Ex :

http://img153.imageshack.us/img153/9...nstitrebrl.png


Voila, si quelqu'un sait comment mettre cela en place, merci d'avance pour votre aide :)

Il y a déjà eu un cas similaire il n'y a pas très longtemps.

Pour compter, il faut grouper sur id_table1. On fait donc une jointure supplémentaire sur la sous-requête de comptage :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

SELECT id_table1, var_table1, id_table2, var_table2, tmp.Nombre FROM table1 LEFT JOIN inter USING ( id_table1 ) LEFT JOIN table2 USING ( id_table2 ) INNER JOIN ( SELECT table1.id_table1, COUNT(*) AS Nombre FROM table1 LEFT JOIN inter USING ( id_table1 ) LEFT JOIN table2 USING ( id_table2 ) GROUP BY table1.id_table1 ) AS tmp ON tmp.id_table1 = table1.id_table1

---

C'est parfait, merci beaucoup pour cette aide.

Vous n'avez pas précisé votre SGBD c'est dommage.
S'il les supporte, une fonction de fenêtrage vient à bout de ce genre de problème très simplement :

Code:

---

1 2 3 4 5 6 7 8

SELECT t1.id_table1, t1.var_table1, t2.id_table2, t2.var_table2, count(*) over(partition by t1.id_table1) as nombre FROM table1 t1 LEFT OUTER JOIN (inter it INNER JOIN table2 t2 ON t2.id_table2 = it.id_table2) ON it.id_table1 = t1.id_table1;

---

Trois remarques :

1. Dès que vous avez plus d'une table dans une requête, utilisez toujours des alias de table et préfixez toutes les colonnes partout dans la requête
2. N'utilisez pas USING, vous économisez trois secondes d'écritures mais vous perdez en souplesse - c'est moins pire que NATURAL JOIN cela dit
3. Comme vous avez une clef étrangère de inter vers table2, vous ne pouvez pas avoir de idtable2 référencé dans inter qui n'existerait pas dans table2.
   Aussi la dernière jointure externe est supperflue, regardez comment j'ai repris ce bloc. Les parenthèses que j'ai écrites ne sont pas obligatoires.

Les screenshots de sa table semble indiquer qu'il utilise phpmyadmin, donc MySQL, donc pas de fonctions de fenêtrage.

D'ailleurs, j'en profite pour poser une petite question par rapport à la remarque #1 :

Citation:

---

Envoyé par sqlpro

Surnommez vos tables avec des alias les plus courts possible. Évitez de préfixer les colonnes non ambigües.

---

(source)

Bref, que faut-il privilégier et pourquoi ?

Disons que pour la machine, les colonnes non ambigües ne posent pas de problème, on gagne en trafic réseau (requêtes plus courtes).

Maintenant, imaginez une requête avec vingt tables, vingt colonnes dans le select, dix dans le where plus toutes les jointures, où tous les noms de colonnes sont uniques.

N'aliasez rien, donnez la requête à un collègue et posez-lui une question triviale. S'il est normalement constitué, il devrait vous maudire pendant l'exercice !

Je reste sur ma position, plus d'une table => aliasez toutes toutes toutes les colonnes.
Une requête appelée 2.000 fois devrait être dans le cache avec des variables de liaison ou en procédure stockée ; SQLPro a peut-être changé d'avis depuis 2003.

Perso, j'utilise les alias dès qu'il y a jointure parce que c'est moins chiant à écrire avec des alias que sans.
Et quand j'utilise les alias, je les utilise partout dans la requête et pour toutes les colonnes. Pas d'ambiguïté dans la lecture !

Je le fais aussi, mais après avoir lu le post de Waldar, je me suis souvenu avoir déjà lu le contraire sur le site de SQLPro, alors je me posais la question :-p

Merci pour les réponses.