Discussion :

[Manu_Karpov]

Mon problème parait simple quand il est ennoncé, mais je tourne en rond depuis pas mal de temps
, et il faut que je trouve une solution...

Sous forme simplifiée voici la structure dont je dispose
Il n'y a qu'une table FACTURES
avec 3 colonnes : NUMFACT, DATEFACT, VENDEUR

Je veux obtenir les 5 dernières factures passées par chaque vendeur, et cela en une seule requête

Merci d'avance à ceux qui vont se pencher sur mon pb

[pifor]

Les premiers peuvent aussi être les derniers :http://oracle.developpez.com/faq/?page=3-1#rownum

[remi4444]

Si ta table n'est pas trop ennorme, tu peux passer par les fonctions analytiques:

Code :

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

1
2
3
4
5
6
7
8
 
select * from 
  (
   select NUMFACT, DATEFACT, VENDEUR,
   row_number() over (partition by VENDEUR order by DATEFACT desc) posit 
   from FACTURES
  )
where posit <= 5

[PpPool]

Si ta table n'est pas trop ennorme, tu peux passer par les fonctions analytiques:

bonjour remi444

juste au passage pq fais tu cette remarque sur les fonctions analytiques ?

j'ai observé pour ma part des résultats très probants sur des tables relativement importantes (>1M) avec les fonctions analytiques versus GROUP BY+HAVING pour avoir le même résultat.

je me souviens même d'un tuto sur ce site de Laly qui fournissait des traces significatives au niveau des I/O.

Merci de ton avis

[remi4444]

Oui, ça sera toujours meilleur qu'un group-by/having. Mais dans ces 2 cas il faut savoir que l'acces à la table sera complet. Dans l'hyposèse ou il y a peu de vendeurs avec des milliers de factures chacun, la requête va se fatiguer pour rien à donner un numéro à chaque facture alors que seules les 5 dernières sont interressante. Dans ce cas là il faudra réfléchir à faire un index sur le couple (VENDEUR/DATEFACT ) avec l'option "DESC" tant qu'a faire, puis faire une requete à base de "order-by desc" et de rownum. Oracle utilisera alors du "COUNT-STOPKEY" ce qui évitera de parcourir toute la table.

[PpPool]

Oui, ça sera toujours meilleur qu'un group-by/having. Mais dans ces 2 cas il faut savoir que l'acces à la table sera complet. Dans l'hyposèse ou il y a peu de vendeurs avec des milliers de factures chacun, la requête va se fatiguer pour rien à donner un numéro à chaque facture alors que seules les 5 dernières sont interressante. Dans ce cas là il faudra réfléchir à faire un index sur le couple (VENDEUR/DATEFACT ) avec l'option "DESC" tant qu'a faire, puis faire une requete à base de "order-by desc" et de rownum. Oracle utilisera alors du "COUNT-STOPKEY" ce qui évitera de parcourir toute la table.

je me demandai s'il n'y avait pasautre chose que je ne savais pas sur les fonctions analytiques.
On est d'accord.
Merci encore de ta réponse

[fsmrel]

Je veux obtenir les 5 dernières factures passées par chaque vendeur, et cela en une seule requête

Supposons que le numéro de facture soit représenté par l'attribut Fact_No et que le critère soit la date de facture, Fact_Date :

Code :

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

1
2
3
4
5
6
7
8
 
Select Distinct x.Fact_No, x.Fact_Date  
From   Factures As x
Where (Select Count(*)
       From   Factures As y
       Where  y.Fact_No = x.Fact_No
       And    y.Fact_Date > x.Fact_Date) < 5
Order by Fact_No, Fact_Date ;

Je n’ai pas testé, donc à vérifier...

[remi4444]

Le principe est beau, mais en matiere de performance c'est une catastrophe, car l'optimiseur n'est pas assez malin pour traduire cette requête en classement/comptage...

a vérifier là aussi...

[fsmrel]

Le principe est beau, mais en matiere de performance c'est une catastrophe, car l'optimiseur n'est pas assez malin pour traduire cette requête en classement/comptage...

Pour être objectif, passer par un EXPLAIN PLAN et tester...

Si les résultats confirment l'incantation, soit, et chercher autre chose, mais de grâce, pas d'a priori.

Comme disait Henri Poincaré, "L'intuition trouve, le raisonnement prouve".

Je rappelle que sur la base de la seule intuition, SQL n'aurait jamais vu le jour. Il a fallu que Don Chamberlin et son équipe construisent le prototype System R et mesurent et remesurent pour arriver à la conclusion surprenante que SQL était plus performant que les SGBD de l'époque (non relationnels et pour cause), cela contre toute attente...