Bonjour à tous,

Je suis actuellement en train de réaliser un site web et je suis confronté à un problème plutôt compliqué.

Tout d'abord, le contexte d’exécution : c'est la bdd postgresql, qui permet de réaliser des fonctions dans un langage très similaire au plsql d'oracle. Même si la solution est compliqué, je suis preneur.

Voici le problème :

La requête sera exécuté sur une seule table contenant deux champs :

Table : stat
champ 1 : membre -> id du membre (integer [0..N])
champ 2 : delta -> (integer [0..N])

Le problème peut paraître triviale, je souhaite récupérer les membre dans l'ordre de delta croissant
(SQL : SELECT membre, MIN(delta) AS delta FROM stat GROUP BY membre ORDER BY delta)


Exemple de tuples :

membre | delta
1 | 10
2 | 10
2 | 23
1 | 35
3 | 3
4 | 42

La requête précédente nous renverra:

membre
3
1
2
4

On pourrait penser que cela est bon, mais mon application complique ici la tâche, en effet, le Min(delta) du membre 1 et 2 sont identique. Or dans ce cas, j'aimerai aller chercher le delta suivant (récursivement) des membres égaux. Le résultat attendu est donc le suivant :

membre
3
2
1
4

Voici donc mon problème, il est possible de le résoudre via une fonction pl/pgsql (langage de postgresql), mais si possible, en une seul requête ce serait l'idéal.

Je vous remercie d'avance si vous prenez du temps pour mon problème.

select membre
from (select membre,
             max(x) clef
      from (select membre,
                   array_agg(delta) over (partition by membre order by delta) x
            from t) a
      group by membre) b
order by clef;

Ca c'est de la requête! Pourriez vous me donner des détails sur la fonction "array_agg"? Et niveau performance, est-ce correcte? (sur une table qui contient 10000 tuples par exemple). Merci beaucoup en tout cas, je teste cette requête ce soir.

Pour arra_agg je te renvoie à la doc; il y a trois choses en fait, array_agg à proprement parler, son emploi comme "windwing function", et les opérateurs sur tableaux pour le tri.
Les performances ne seront pas correctes: elles seront nettement meilleures que tout ce que l'on peut faire en pgSQL. Et 10000 lignes, ce n'est rien (j'ai passé pas mal de temps chez des opérateurs télécoms et des banques à optimiser leurs programmes, tu peux me croire). Le seul problème c'est si tu as des millions de deltas par membre, mais si c'est quelques dizaines voire centaines, cela devrait passer.

Ok merci beaucoup!

Edit:
J'ai testé ta requête, les résultats sont très bons! Avec plus de 100000 tuples pour 1000 membres, la requête prend 969.461 ms sur mon ordinateur portable assez récent mais pas équivalent à un bon serveur. Merci infiniment! Cela va rendre mon travail tellement plus simple..