Discussion :

[Waldar]

Chaque requête, chaque environnement pose ses problèmes.
Actuellement je travaille dans sur un DWH (Oracle , mais la logique est la même) où les I/O ont été optimisés aux petits oignons par l'équipe système (disques I/O fusion, SSD en veux-tu en voilà).
Bref, les I/O sont rarement un problème.
Avec 1 To de RAM, on n'a pas non plus de soucis de ce côté là.
Ce qui nous limite c'est le CPU.

Et les tris des fonctions de fenêtrages sont coûteux.
En fonction des données, j'ai déjà optimisé des requêtes par des facteurs cinq à dix en remplaçant des fonctions de fenêtrage par des bons vieux agrégats.
Et l'inverse est vrai également.

[SQLpro]

Une recherche rapide sur "ROW_NUMBER 2005 performance" :
http://jerschneid.blogspot.sg/2008/0...ber-sucks.html
http://thehobt.blogspot.sg/2009/02/r...denserank.html

déjà la première comparaison est stupide puisque l'on compare de l’itératif à de l'ensembliste. Elle n'a donc aucune valeur. En sus on ne compare que sur un jeu de données fixe dont le nombre de lignes est le même. C'est encore plus stupide !

Or la magie du SQL c'est que le comportement des temps de réponse n'est que très rarement linéaire !

Donc, il n'est pas rare qu'en fonction de la cardinalité, la stratégie d'attaque des données et les algorithmes de traitement des opérations changent et que ce qui apparaissait avantageux avec un faible nombre de ligne devient catastrophique avec un grand nombre.

pour exemple, regardez les conditions du benchmark effectué sur un type de requête avec différentes écritures que j'ai réalisé ici :
http://blog.developpez.com/sqlpro/p9...alles_en_sql_1
On part de 1000 lignes, pour aller successivement à 1 millions de lignes.
Vous pourrez remarquer que pour certaines requête, la durée intrinsèque diminue en fonction de l’augmentation du nombre de lignes, notamment pour les requêtes 5 et 6 lors du passage de 1000 à 3000 lignes une fois les bons index posaés !

A +

[pcaboche]

déjà la première comparaison est stupide puisque ...

Ok, je n'ai pas pris le temps de décortiquer chaque requête, méthodologie, etc.
Ce qui m'a mis la puce à l'oreille, c'est le nombre de gens qui se plaignaient de la lenteur sur 2005 (à tort ou à raison, je ne sais pas).

Cela ne m'a pas empêché d'utiliser le ROW_NUMBER à plusieurs reprises, avec des performances acceptables (mais ce n'était pas sur des millions d'enregistrement).

Si en plus ça supporte bien la charge, alors tant mieux ! (parce que c'est quand même bien pratique !)