Discussion :

[mactwist69]

Hello la communauté,

N'écrivant des requêtes (non basique) que très rarement, je viens demander de l'aide car j'ai peur pour ses performances.

Disons une table avec 100 000 Lignes, avec comme colonne :
- ID (unique)
- TYPE_P (le type, il existe 4 types parmi toutes les lignes)
- DATE_E (date d'enregistrement de l'enregistrement)
- TEXTE_E (une info)

Ce que je veux ramener :

- je veux ramener autant de ligne qu'il y a de types, donc 4
- pour chaque type, remonter la ligne de la plus haute date

J'aurai pu utiliser Group By sur le type et faire un MAX sur la date, mais Quid de TEXTE_E ? se sera au hasard ?

Du coup, si je devais absolument trouver une solution, j'aurai fait :
4 requêtes relié par des UNION, avec pour chacune d'elle un WHERE qui cible un seul TYPE_P (en dur donc), trié par date décroissant, LIMIT 1

Mais j'ai peur des performances de cette requête... Il va passer 4 fois dans toute la table...


Si quelqu'un peut m'orienter sur une solution plus propre, je suis preneur.
Merci

[punkoff]

Bonjour,

Quel est votre sgbd ?

[mactwist69]

Ah oui pardon : SQL Server 2008 R2

[escartefigue]

Utilisez une fonction de fenetrage

[mactwist69]

Bonjour,

Merci de l'info, je n'avais encore jamais entendu.

Je vais étudier ça.

[escartefigue]

Comme ci-dessous :

Code :

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

1
2
3
4
5
6
7
8
WITH XXCTE AS                                                 
   (SELECT  ROW_NUMBER()                                       
            OVER (PARTITION BY TYPE_P ORDER BY DATE_E) AS RANG 
           ,ID, TYPE_P, DATE_E, TEXTE_E                     
     FROM MA_TABLE)                                                 
SELECT ID, TYPE_P, DATE_E, TEXTE_E                         
FROM XXCTE                                                    
WHERE RANG = 1

[DDNetweaver]

Si la date est unique pour un type donné, tu peux faire une requête de ce type

Code :

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

1
2
3
4
5
6
SELECT
   t.ID, t.TYPE_P, t.DATE_E, t.TEXTE_E
FROM
   MA_TABLE t
INNER JOIN
 (SELECT TYPE_P,MAX(DATE_E) as DATE_E FROM MA_TABLE GROUP BY TYPE_P) f on f.TYPE_P=t.TYPE_P and f.DATE_E=t.DATE_E

Mais, en fonction du ratio update/lecture sur cette table, il y a d'autre technique de dénormalisation pour optimiser cette requête très gourmande

[SQLpro]

Comme ci-dessous :

Code :

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

1
2
3
4
5
6
7
8
WITH XXCTE AS                                                 
   (SELECT  ROW_NUMBER()                                       
            OVER (PARTITION BY TYPE_P ORDER BY DATE_E) AS RANG 
           ,ID, TYPE_P, DATE_E, TEXTE_E                     
     FROM MA_TABLE)                                                 
SELECT ID, TYPE_P, DATE_E, TEXTE_E                         
FROM XXCTE                                                    
WHERE RANG = 1

Je te corrige....

Code :

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

1
2
3
4
5
6
7
8
WITH XXCTE AS                                                 
   (SELECT  ROW_NUMBER()                                       
            OVER (PARTITION BY TYPE_P ORDER BY DATE_E DESC) AS RANG 
           ,ID, TYPE_P, DATE_E, TEXTE_E                     
     FROM MA_TABLE)                                                 
SELECT ID, TYPE_P, DATE_E, TEXTE_E                         
FROM XXCTE                                                    
WHERE RANG = 1

A +

[mactwist69]

Merci à tous !

C'est répond exactement à mon besoin, je ne connaissais pas du tout.


Petite question subsidiaire :

J'avais bien sur simplifié le problème pour l'énoncer, j'ai évidemment des petites jointures à faire pour faire apparaître les données qui vont bien,

Je me dis qu'il vaut mieux faire ces petites jointures sur le résultat (le deuxième SELECT), et non pas dans la requête de fenêtrage, n'est ce pas ?

Ou ça change rien ?

[escartefigue]

La CTE crée dans votre cas une table de 4 lignes, donc d'un point de vue performances c'est une circonstance favorable

Après reste à voir vos critères de jointure, sargable ou non, et le volume des tables à joindre

[mactwist69]

Parmi les tables à joindre il y a la table principal de la base de données... Donc plutôt imposante
Donc j'ai mis les jointures à la fin.