[struts][tri] tri Java ou tri SGBD ?

Bonjour,

Je réalise une application J2EE avec le framework Struts. Une des fonctionalités attendues est d'afficher un "top 30" des clients de la boïte selon deux critères choisis parmi 4 (volume et fréquence de livraison, etc.)

Les données se trouvent dans une table d'une base Oracle, avec un enregistrement par client.
J'hésite entre deux méthodes :

- filtrer les clients directement au niveau de la requête SQL, avec un

Code:

---

1 2	SELECT * FROM latable WHERE rownum<=30 ... ORDER BY <critere 1>, <critere2>

---

- coder une classe Java implémentant Comparator pour comparer 2 clients selon des critères donnés. Sélectionner tous les clients de la table (environ 3000), les placer dans un Vector et trier ce dernier grâce au Comparator. Afficher les 30 premiers éléments du Vector.

Quelle solution vous paraît la plus efficace, sachant que les champs pris en compte comme critères de comparaison sont soit numériques, soit des varchar (ex : la fréquence de livraison est de la forme "10101" chaque chiffre représentant un jour de la semaine où le client est livré ou non) ?
Le tri d'Oracle sera-t-il plus performant qu'un tri en Java avec le Comparator ? Le fait que le Vector contienne 3000 objets Client pose-t-il un problème ?

Merci d'avance pour vos suggestions :)

A mon avis c'est au choix.

1- Si tu as un besoin que tous les objets soit en mémoire car tu peux les afficher dans ton déroulement, ou car tu les utilises ailleurs. A ce moment là tu peux utiliser une classe statique pour les stocker (comme une sorte de cache si tu préfères !)

2- Tu en as besoin uniquement pour ton affichage, à ce moment là, laisse faire Oracle qui sera plus rapide que toi. Surtout si tout tes champs sont dans une unique table. Ce sera moins vrai si tu as des jointures multiples.

Donc là, c'est vraiment dépendant de la suite.

J'ai besoin de ces objets uniquement pour un affichage, ils ne sont pas réutilisés.

Merci pour tes recommandations. Quelqu'un a d'autres suggestions ? J'aimerais surtout savoir dans quelle mesure le tri d'un Vector contenant 3000 objets (avec chacun 4-5 propriétés) pourrait gréver les performances...

Pour gréver les performances, c'est relativement simple.
Le serveur de base de données DOIT indexer ces documents, ce qu'il fait normalement régulièrement si tu as de bon DBA.
En revanche tes objets eux ne sont pas indexés, ou alors un petit peu à la création (et encore...)
En plus c'est typiquement le boulot d'Oracle sur des requetes aussi simple que çà. Cela dépend vraiment de ta requete, si tu joins sur 5 ou 6 tables ayant chacune 150 000 lignes çà peut être moins rapide c sûr ...

Euh, théoriquement les index sont inutiles dans mon cas puisque le tri des enregistrements nécessite forcément un full scan de la table, et qu'il n'y a pas de jointures...

Ce que je voulais savoir, c'est juste si l'instanciation et l'ordonnancement de 3000 objets était faisable en termes de performances ou non (sur un serveur J2EE Oracle 9iAS). De plus, la méthode de tri Collections.sort() de Java est-elle aussi optimisée que le tri Oracle ?

Oui si c'est que tu veux savoir c'est effectivement possible de faire une instanciation de 3000 documents et de faire le tri en java.
Je ne sais pas si la méthode Collections.sort() est optimisé, mais je pense que oui.
En revanche, tu vas chargé à fond ta mémoire, pour la décharger après, çà par contre c'est plutôt à éviter si c'est pour du besoin ponctuelle car çà risque de ralentir les autres demandes...
Enfin à toi de voir.
Ah oui, et puis l'avantage d'Oracle c'est que quand tu ajoutes un critere de tri, tu n'es pas obligé de changer ton code Java.

Clairement c une truc a faire avec la base.

@+

Bon, je crois que je vais opter pour la solution de la base de données, ça sera en effet plus optimisé.

Merci pour vos réponses :wink:

si tu as moyen d'ecrire le sql, tu peux utiliser LIMIT et juste retourner les resultats que tu veux afficher.

en faisant attention, tu peux garder ton curseur en session et implementer la pagination de cette facon. Ca sera plus rapide que de charger les 3000 enregistrement.

Honnetement 3000 je trouve que c pas grand chose.

Alors que 3000 objets JAVA c'est enorme.

Pe devrais-tu faire uen procedure stockée si tu as peur pour les performances.

@+