Discussion :

[yaka_balboa]

Bonjour à tous !

Me voilà bloqué sur un problème qui me paraît pourtant simple.
Je souhaiterais afficher par genre le nombre d'usagers (T_Usagers) ayant effectué au moins un passage (T_Passages) dans l'année 2017.

Voici la requête que j'utilise :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
select sexe, count(1)
from T_Usagers as tu
where tu.IPP in (
   select tp.IPP
   from T_Passages as tp
   where tp.DatePass between #01/01/2017# and #12/31/2017#)
group by sexe;

Voici les volumes des tables :
T_Usagers = 5000
T_Passages = 2000

Le champ IPP est la clé primaire de la table T_Usagers et il est indexé dans la table T_Passages.
J'ai également ajouté un index sur le champ DatePass.

Et bien malgré tout, cette requête prend environ 11 secondes, ce qui me parait beaucoup ...

Si vous avez des idées, je suis preneur. Merci !

[yaka_balboa]

Re,

Finalement je viens de tomber sur une solution :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
select sexe, count(1)
from T_Usagers as tu
inner join (select distinct tp.IPP from T_Passages as tp where tp.DatePass between #01/01/2017# and #12/31/2017#) td on td.IPP = tu.IPP
group by sexe

Et là, le résultat est instantané ...
Mais je ne trouve pas ça d'une propreté extraordinaire ...

Vous pensez que c'est la bonne approche ?

[tee_grandbois]

Bonjour,

Mais je ne trouve pas ça d'une propreté extraordinaire ...

C'est quoi, pour toi, la définition d'un "code propre" ?
Parce que, finalement, tu as trouvé tout seul la solution qui fonctionne bien et plus rapidement, n'est-ce pas là l'essentiel ?

[yaka_balboa]

Disons que je m'attendais à une solution plus en conformité avec les autres SGBD.
L'utilisation de la clause IN me paraît plus "logique" qu'une sous-requête appelée dans un INNER JOIN.

Mais effectivement, ma solution fonctionne.

Je passe le sujet à résolu.

[tee_grandbois]

L'utilisation de la clause IN me paraît plus "logique" qu'une sous-requête appelée dans un INNER JOIN.

INNER JOIN est aussi présente dans d'autres SGBD.
En développement, en principe, on choisit la solution la plus performante et c'est ce que tu as fait

[marot_r]

Et on peut dire que IN ce n'est pas très propre car cela n'utilise pas les jointures qui sont des outils de base de toute BD relationnelle.

De plus IN est réputé pour être un oppérateur lent donc à éviter si possible.

A+