Où stocker des requêtes SQL ?

**VinceSSJ** · 11/06/2012, 14h55

Bonjour,

Je voudrais avoir votre avis et vos conseils sur quelque chose que je n'ai jamais fait et qui traite sur le stockage de requêtes SQL.
Je travaille sur une application JEE qui possède une architecture pour moi assez complexe et que j'ai comme devoir d'optimiser.

Dans cette application, les requêtes SQL sont toutes stockées dans la base de données du serveur applicatif. Ce qui fait que pour effectuer des recherches et des traitements sur les BD, l'application doit tout d'abord accéder à la BD pour remonter la bonne requête, pour ensuite retourner dans la BD pour effectuer la requête remontée.. C'est le "serpent qui se mord la queue" comme on me l'a si bien dit

J'ai donc dans l'idée de placer ces requêtes "dans" l'appli pour que les accès soient moins longs.

Question : Où stocker ces requêtes ? Directement dans le code ? Dans un fichier ? Si oui quel genre de fichier ?

Je précise que l'appli possède un EJB entièrement consacré aux accès à la BD et qui a comme rôle par exemple d'aller chercher des requêtes, de faire les connexions, etc... Donc il faudra de toutes manières que je modifie cet EJB en fonction de ce que je vais faire.

Dans la table qui contient les requêtes, il y a 2 colonnes, une qui contient la requête à proprement parlé et une autre qui est le nom de cette requête.

Merci d'avance pour vos réponses !

**Népomucène** · 11/06/2012, 15h05

Combien y-a-t-il de requêtes ?
Qui s'occupe de leur maintenance (création/modification) ?

S'il y a beaucoup de requêtes et/ou on doit souvent les modifier
alors il faudra probablement les laisser en base de données

**VinceSSJ** · 11/06/2012, 15h16

1. Dans la table il y a 100 lignes. Mais dans ces 100lignes, il y a certaines ligne qui sont des "parties" de requêtes. Par exemple :

REQ_SELECT_NUM : Select x from y where o=p
REQ_SELECT_NUM : And u=m
REQ_SELECT_NUM : And n=d

Il y a donc 3 lignes qui possèdent le même nom. La première ligne est la "base" de la requête, tandis que les autres lignes ne sont que les compléments si besoin.
Donc au final je dirais qu'il y a 70 requêtes dans la table. Les 30 autres sont les compléments.

2. En fait, logiquement c'est le responsable SI qui s'occupe de la maintenance, mais depuis sa création en 2008, rien n'a été rajouté ni modifié dans l'appli. Et ça compte pas l'être dans le futur.

**goute** · 11/06/2012, 15h25

Tu les laisses dans la bdd, tu les charges à l’exécution de l'application, puis tu les enregistres dans une variable de session. Comme ça tu ne fais qu'un seul accès a la bdd.

**fxrobin** · 11/06/2012, 15h26

pour ma part, j'irai mettre tout ça dans un fichier de properties ou encore dans un fichier XML mis dans WEB-INF ou dans META-INF.

vu tes contraintes sur les "noms identiques" j'opterais pour un fichier XML genre

Code :

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

1
2
3
4
5
6
7
8
9
10
<?xml version="1.0" encoding="UTF-8" ?>
<liste-requetes>
   <requete id="truc-muche">
       <base>Select x from y where o=p</base>
       <complement>And u=m</complement>
       <complement>And n=d</complement>
   </requete>
  .. etc ..
  .. etc ..
</liste-requetes>

Le tout parsé en DOM ou en JDOM.

mais surtout pas en base de données ...

**Népomucène** · 11/06/2012, 15h31

Pour ne pas tout remonter "à la main" dans le code,
tu peux, au moment où l'application est lancée, charger toutes tes
requêtes dans un Map ou un Arraylist (en mémoire donc + rapide)

**fxrobin** · 11/06/2012, 15h51

Envoyé par fxrobin

Le tout parsé en DOM ou en JDOM.

il était évident dans ma réponse que le DOM doit être conservé en mémoire et pas parsé à chaque fois, ce qui revient à une Map ou une List en mémoire

**Népomucène** · 11/06/2012, 16h00

Eh bien c'est une belle unanimité ! tout le monde est d'accord sur le principe
de charger les requêtes en mémoire !

Il ne te reste plus qu'à choisir la forme qui te conviens le mieux
(variable de session, Map, List, etc...)

**VinceSSJ** · 11/06/2012, 16h19

Merci beaucoup pour toutes vos réponses !!

Je pense qu'une Map pourrait faire l'affaire non ? Une clé (nom), une valeur (requête)

A moins que ça soit trop lourd pour juste ce que j'ai à faire ?

Donc si je résume, je fais mon XML, je parse une seule fois au lancement de l'appli (avec JDOM qui a l'air trèèèèèès sympathique

http://cynober.developpez.com/tutoriel/java/xml/jdom/ ) et ensuite je retrouve mes requêtes comme je veux

Par contre il faut que je modifie mon EJB Connexion Factory qui possède des méthodes du genre ArrayList<String> selectPart(nom_de_requete) qui ont pour rôle par exemple de remonter les requêtes, etc.... Mais là en fait j'aurais juste à chercher dans le XML au lieu de chercher dans la bdd si je comprends bien !

En plus cette méthode selectPart je l'ai mise en cache actuellement donc elle serait toujours mise en cache ça n'y changerait rien

**fxrobin** · 11/06/2012, 17h05

Envoyé par VinceSSJ

Je pense qu'une Map pourrait faire l'affaire non ? Une clé (nom), une valeur (requête)

A moins que ça soit trop lourd pour juste ce que j'ai à faire ?

le problème de la Map (et aussi son avantage) c'est une clé, une valeur ...
or tu as écris plus haut : une clé, plusieurs valeurs ... voilà pourquoi je t'ai orienté vers une Structure XML parsée avec JDOM :

Facilement maintenable (fichier texte), et analysable (parsing) ultra facile.

sinon si tu veux une clé, et plusieurs valeurs, tu as la "MultiMap" du projet Apache Commons :

http://commons.apache.org/collection.../MultiMap.html

**VinceSSJ** · 11/06/2012, 17h55

Ah mais oui où ai-je la tête !!!!!!! En plus j'avais eu exactement le même problème avec une autre manip'

Oui donc Map je laisse de côté.

je pense vraiment utiliser JDOM qui me parait facile à mettre en place, mais maintenant le truc c'est comment mettre en mémoire ce qui aura été parsé justement..
Est ce que les JDOM consomme beaucoup de ressources (du moins plus qu'une ? Si non alors ça vaudrait peut être pas le coup de mettre en mémoire, si ?

**fxrobin** · 11/06/2012, 18h47

tu gardes le JDOM en mémoire avec "static" ou un Singleton (ce qui au final revient au même). JDOM conserve une hierarchie d'objets en mémoire, issus du parsing du fichier XML.

**VinceSSJ** · 12/06/2012, 10h05

En effet un static devrait faire l'affaire

Par contre pourquoi mettre le XML dans WEB-INF ou META-INF, est ce que ça ne suffirait pas de le mettre directement dans le jar des EJB ?

**fxrobin** · 12/06/2012, 10h42

si si, biensûr.

Et tu le récupères un InputStream dessus avec un getResourceAsStream

**VinceSSJ** · 12/06/2012, 11h26

Ah je me disais aussi

Pourquoi un InputStream ? Pour utiliser le JDOm dans mes EJB ?
Ce que je veux c'est juste le lire, dans la doc que j'ai postée au dessus ils se servent juste d'un

Code :

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

document = sxb.build(new File("Exercice2.xml"));

pour parser et ensuite y'a juste à récupérer les éléments avec un iterator qui parcourt la liste

Sinon j'ai commencé à créer mon fichier xml. En fait j'ai plusieurs colonnes dans la BD donc j'ai adapté en fonction

Du genre :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<liste-requetes>
   <requete id="REQ_BDGDP_DDEB">
       <liste-parties>
            <partie>
                <string>Select t.idTache, t.tid, t.labo, t.etude, t.dateDeb, t.duree, t.libelle, t.dateInit, t.dureeInit, t.annotation, t.technicien, t.libelleInit, t.derniereModif, t.modifPar From Tache t Left Outer Join Periode p On (t.idPeriode = p.idPeriode) Where t.dateDeb >= ? And t.dateDeb < ? And p.niveau = ? </string>
                <ordre>1</ordre>
                <reqdesc></reqdesc>
            </partie>
            <partie>
                <string>t.labo</string>
                <ordre>2</ordre>
                <reqdesc></reqdesc>
            </partie>
       </liste-parties>
   </requete>
    etc...
    etc...
</liste-requetes>

**fxrobin** · 12/06/2012, 11h41

le getResourceAsStream te permet d'aller chercher un fichier contenu dans l'EJB JAR ou dans le META-INF.

Si tu fais avec "File()" tu devras fournir le chemin complet ... et donc ça va dépendre du déploiement ... donc voilà pourquoi on fait avec "getResourceAsStream"

**VinceSSJ** · 12/06/2012, 11h46

Très bien merci je n'avais pas vu ça comme ça effectivement

Par contre, quand je vais utiliser ma méthode selectPart(requete), la méthode va appeler une méthode de ma classe JDOM pour chercher la requête dans le fichier XML. Cette recherche n'est qu'une "simple" boucle qui parcours le xml parsé avec un iterator.
Mai justement cette recherche, coute t'elle moins en termes de ressources qu'une recherche dans la base de données ?

Dans tous les cas, une fois la recherche effectuée, la requête trouvée dans le xml est placée dans le cache

Mais je demande surtout pour les méthodes non cachées..

**fxrobin** · 12/06/2012, 12h49

oui ça coûte moins cher !

mais je te conseille d'aller piocher les informations dans le JDOM avec des requêtes XPATH ce qui t'évitera de faire des parcours en boucle et le tout sera bien optimisé :

http://zedros.developpez.com/tutoriels/java/xml/xpath/