Tout est dans le titre : comme ce qui est fait sur n'importe quel site de vente en ligne, je souhaiterais afficher sur une JSP le résultat d'une grosse requête (plusieurs centaines de lignes par exemple) par paquets : par exemple 20 lignes par page, puis on doit cliquer sur "suivant" pour avoir les 20 suivantes,etc.
Je me demande par où commencer : est ce que la solution se situe dans la requête SQL, dans l'exploitation du ResultSet ? A priori, une solution en faisant un select sur la clé primaire (par exemple WHERE cle>valeur AND cle<=valeur+n) ne m'irait pas car je souhaiterais trier mes enregistrements.
 
J'utilise JDBC avec une base Access (meme si c'est pas possible sur une base comme ca, ca m'intéresserait de savoir comment on fait sur un SGBD qui va bien).
 
Merci...

c'est assez simple.
 
Ta requete prendre un nombre maximum de resultats a prendre et l'index ou il faut démarrer.
 
 

Bah, a mon avis, garder le ResultSet ouvert, pkoi pas, mais tu es obligé de garder le Statement ouvert aussi, donc, la connection avec....Pas top top....
Après, tu peux choisir de faire une requête qui te renvoie les éléments du i° au j°...mais tu auras une requête par action sur le bouton "suivant" ou "précédent"
La troisième solution consiste à sauvegarder la totalité de tes résultats dans un objet, qui permet de récupérer les éléments qui t'intéressent...
Après, le choix de la solution dépend de plein de choses : 'poids' des requêtes, etc, etc..

le truc c'est garder 100 000 résultats si tu regargede seuelemnt les 50 premier en moyenne c'est pas super efficient ...

Merci pour vos réponses.

Justement, c'est ça que je ne sais pas faire    tu pourrais détailler un peu ?
 

Ca ne me choque pas trop a priori. C'est de toute facon moins couteux que de redemander une connexion à chaque fois.
 

En mémorisant où j'en suis dans la session je pourrai m'en sortir avec une seule requete.
 

Ca, je ne peux définitivement pas le faire : le nombre d'objets sauvegardés en mémoire est trop important (plusieurs centaines voire plusieurs milliers d'enregistrements).
 

En fait je bosse sur un modèle générique d'architecture et je développe un petit exemple pas très significatif.En tout cas ce que je fais doit supporter des requetes retournant des résultats très importants (en nombre de lignes et de champs).

En SQL, t'as rien pour dire que tu veux les résultats de n à m.
Par contre, les gros SGBD pallient à ce manque du SQL.
Genre, avec SQL Server, tu peux faire

(salut les p'tits clous ) qui te sélectionnera les 50 premiers enregistrements (avec ça, tu peux te démerder pour faire une sélection des enregistrements du 50° au 100° avec des requètes imbriquées et un classement, j'développerai si tu veux !)
acec Oracle, j'crois que t'as une contrainte MAWROW ou ROWMAX:

 
Sinon, pour ta mise en page, regarde un peu ça :
http://jsptags.com/tags/navigation/pager/

 
Faux!! Si tu as 25 péquins qui font la requête en même temps, et qui bloquent chacun une connection, qui a l'air d'un con???
 
 

 
Bah, c'est un peu la même chose...
Ou sinon, tu te fais une API de recherche, qui gère un cache de résultats, tu sera moins emmerdé..

Merci Gringo.
  pour les p'tits clous (ah la la, Marc Toesca, que de souvenirs)
 
Je viens d'essayer le coup du TOP dans Access, ca marche. Par contre pourrais tu développer ton histoire de "requetes imbriquées et de classement" STP ?

GFive:
Que stockerais tu dans le cache ? une liste d'identifiants par exemple ? Parce que je ne peux pas me permettre de stocker des milliers objets en mémoire...
 
Autre chose : quand tu parles d' "une requête qui te renvoie les éléments du i° au j°", sais tu comment je pourrais le réaliser ?
Pour l'instant, j'arrive à faire ca du 1er au 50e enregistrement, mais apres...
 
J'en profite pour remercier tout le monde de m'aider.C'est la première fois que je poste une question et c'est vraiment sympa que des gens me répondent  

swgreedo a écrit a écrit : Merci Gringo.   pour les p'tits clous (ah la la, Marc Toesca, que de souvenirs)   Je viens d'essayer le coup du TOP dans Access, ca marche. Par contre pourrais tu développer ton histoire de "requetes imbriquées et de classement" STP ?

 
Ouais, j'voulais pas développer pr rien, ms si ça t'interresse, c parti :
en fait, tu vas faire un truc du genre ça :
Rouge ---------------------------------------------->
Vert   -------------------------->
Bleu                     <------------
(merde, j'arrive mêmep as à metttre des couleurs ! )
 
Où on a, en rouge l'ensemble des enregistrements de ton select, en vert, la restriction par le 1er top, et en rouge les résultats que tu récupères à la fin.  
 
En rouge, c la requète :

 
En vert :

("UNCHAMP"  peut être ta clé primaire ou autre chose. c bien si ce champ a une valeur différente pr chaque enregistrement)
 
En bleu :

(UNCHAMP est 2 fois le même champ bien sur !)
 
J'ai pas testé, mais en gros, ça doit être un truc comme ça.

Merci    
Je vais tester ca...

Tu peux aussi utiliser le ROWNUM ("select * from (select * from matable) where ROWNUM between 1 and 10", par exemple) dans ta requete SQL et faire un ptit dev JSP pour spécifier eventuellement le nombre d'enregistrements max, et définir le nombre de pages, etc ...
 
Edit : attention, à moins de passer par des vues, le ORDER BY sur un champ ne fonctionnera plus, le ORDER BY se fera systématiquement par le ROWNUM

el_gringo tu me déçois là
les requetes imbriquées spabieng    
c'est pas darklord qui va me contredire

--greg-- a écrit a écrit :   el_gringo tu me déçois là les requetes imbriquées spabieng     c'est pas darklord qui va me contredire

 
...J'te déçois !?
Ouah, ça veut dire qu'un instant j'étais monté dans ton estime ?
 
Trève de conneries, t'as mieux comme solution pour SQL Server ?
Et, à part que c pas bien, tu reproches quoi aux requètes imbriquées ?
Parce que, niveau perfs, si tu veux une centaine d'enregistrements sur une base qui en a qqs millions, j'peux te dire que t gagnant, ms alors qqch de terrible !

Moi betement, j'aurais fait un bean contenant l'ensemble des resultats, attaché à la session, et dans lequel je vais piocher selon le numero de la page demandée...
Mais c'est sur que ca fait sortir et conserver tous les resultats pour n'en afficher que quelques-uns

ben je ne sais pas coment le truc là, TOP fonctionne mais bon.
admetton que tu as un champ ID dans ta table.
meme s'il nest pas "continu", tant que tu sais l'id a partir duquel tu veux afficher, c bon
 
tu fais ça

en remplaçant X par l'id du dernier enregistrement affiché.
tout betement.

jte dis pas la tronche de ton servuer avec 100 users et 10000 records dans ta table.
swap swap swap swap swap swap swap swap swap swap swap swap swap swap swap swap swap swap

En fait c'est ca mon probleme : ca fait deux mois que je fais des applis cote serveur, et j'ai jamais travaillé que sur un serveur de test ou je suis le seul user. Mais je me doutais quand meme que c'était pas la bonne solution hein..

DarkLord a écrit a écrit :

Ben koi, t'as jamais débuté ?

 
Bah ouais, ms bon, 'faut admettre que t'as un champ ID !!!
Souvent on choisis pas soit même la structure de la base de données sur laquelle notre appli diot bosser (c mon cas, et je pense pas être le seul !)

 
Bah oui, mais sur les grosses tables (avec plein d'enregistrements), c la requète SQL qui est longue, donc l'intéret de répartir les resultats est nul si la requèete SQL est tjs la même !

 
Non, ms c vrai que tu devrais un peu tester ton appli ds le cas ou il y a plusieurs utilisateurs, on sait jammais, si ça s'trouve y aura plus d'une personne à la fois sur les web-apps que tu développes !
Même si t tout seul, t'as des logiciels de tests qui permettent de simuler des requètes en simultané. Moi j'utilise JMeter (google power !), c un peu chiant à prendre en main, mais vachement bien.

El_Gringo a écrit a écrit :     Non, ms c vrai que tu devrais un peu tester ton appli ds le cas ou il y a plusieurs utilisateurs, on sait jammais, si ça s'trouve y aura plus d'une personne à la fois sur les web-apps que tu développes ! Même si t tout seul, t'as des logiciels de tests qui permettent de simuler des requètes en simultané. Moi j'utilise JMeter (google power !), c un peu chiant à prendre en main, mais vachement bien.

Non en fait je développe une appli pour mon patron, il sera le seul à s'en servir, mais comme le seul logiciel qu'il maitrise c'est Internet Explorer...

y'a un minimum quoi, t'as bien un champ qui peut faire office d'id.
si y'en a pas c'est une erreur de conception

--greg-- a écrit a écrit : y'a un minimum quoi, t'as bien un champ qui peut faire office d'id. si y'en a pas c'est une erreur de conception

 
Chez moi y en a pas.
Et c pas moi qui ai conçu !

 
et a propos on vient me dire que je suis pretentieux!!

--greg-- a écrit a écrit :   et a propos on vient me dire que je suis pretentieux!!

 
Je m'suis fait un ennemi.
 
Un de nous 2 est de trop sur ce forum, gringo !
Dégaines si t un homme.

bon allez ça suffit le pourrissage de topic
ct pour rire hein