Où stocker des requêtes SQL ?

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 ! :P

1. Combien y-a-t-il de requêtes ?
2. 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

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.

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.

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:

---

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 ... :aie:

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)

Citation:

---

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 ;)

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...)

Merci beaucoup pour toutes vos réponses !! :P:P:P:P

Je pense qu'une Map pourrait faire l'affaire non ? Une clé (nom), une valeur (requête) :P 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 :mrgreen: http://cynober.developpez.com/tutoriel/java/xml/jdom/ ) et ensuite je retrouve mes requêtes comme je veux :P

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

Citation:

---

Envoyé par VinceSSJ

Je pense qu'une Map pourrait faire l'affaire non ? Une clé (nom), une valeur (requête) :P 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

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

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 ?

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.

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 ?

si si, biensûr.

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

Ah je me disais aussi :aie:

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:

---

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:

---

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>

---

:ccool:

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" ;)

Très bien merci je n'avais pas vu ça comme ça effectivement :P
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..

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/

Ok merci :P je vais voir tout ça ! Surtout que le XPATH j'ai tâté ça cette année en cours :aie:

Citation:

---

Envoyé par VinceSSJ

Ok merci :P je vais voir tout ça ! Surtout que le XPATH j'ai tâté ça cette année en cours :aie:

---

c'est ce qui s'appelle "monter en expertise" :mouarf:

Re !
Je rencontre quelques petits soucis avec le getResourceAsStream().

En fait je ne sais pas quel chemin indiquer. Pour l'instant je fait un ptit programme test :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

private static InputStream is;   public static void parseXML(){ SAXBuilder sxb = new SAXBuilder(); try{ //On crée un nouveau document JDOM avec en argument le fichier XML //On utilise un getResourceAsStream plutot qu'un File() pour ne pas donner le chemin complet du .xml //Le parsing est terminé Class cl = Class.class; is = cl.getResourceAsStream("PropertiesRequetes.xml"); document = sxb.build(is); } catch(Exception e){} }

---

Mon .xml est dans le même package que cette classe (pour l'instant), et quand j'utilise ensuite

Code:

---

document.getRootElement();

---

Il me sort une Exception de type null (donc sur document je suppose)

oula, ne fait pas de catch exception vide ... s'il arrive pas à lire ton fichier (ce qui est le cas visiblement, puisque le node Root est absent) tu ne sauras pas ce qu'il se passe.

Fais un printStackTrace dedans.

où as tu mis ton fichier XML ?

si c'est dans META-INF, utilise

cl.getResourceAsStream("/PropertiesRequetes.xml");

bon j'ai fait une toute petite démo, comme toi :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

package jdomdemo;   import java.io.IOException; import java.io.InputStream; import org.jdom2.Document; import org.jdom2.JDOMException; import org.jdom2.input.SAXBuilder;   public class JDomDemo {   public static void main(String[] args) throws JDOMException, IOException { SAXBuilder sxb = new SAXBuilder(); InputStream is = JDomDemo.class.getResourceAsStream("fichier.xml"); Document doc = sxb.build(is); System.out.println("Root name : " + doc.getRootElement().getName()); } }

---

le fichier xml nommé "fichier.xml" est placé dans le package "jdomdemo" (tout comme la classe), voici son contenu :

Code:

---

1 2 3 4 5 6

<?xml version="1.0" encoding="UTF-8"?> <racine> <fils>Donnée 1</fils> <fils>Donnée 2</fils> <fils>Donnée 3</fils> </racine>

---

et ça marche correctement.

Voici ce que ça m'affiche :

Code:

---

Root name : racine

---

Donc je pense que tu as sûrement un problème de syntaxe dans ton XML.
Tu es sûr que ton fichier XML est bien formé ?

Merci pour tes réponses une nouvelle fois très efficaces, car j'ai trouvé !
Pour le catch effectivement c'est une faute :oops: Quand j'ai vu que ça me sortait un pointeur null j'ai pas essayé de chercher plus loin... Grossière erreur car en mettant le printStack, il m'a indiqué une erreur à la ligne 81 de mon xml :

Code:

---

<string>t.technicien Is Not NULL And t.technicien <> ''</string>

---

< et > caractères interdits bien sûr... :oops::oops::calim2:

Donc plus qu'a remplacer par les données codées &# 60; et &# 62; et le tour est joué..
Et là ça marche ! :ccool:

Ça m'apprendra à sous estimer les Exception :cry:

tu as aussi "&lt;" et "&gt;" pour respectivement "<" et ">"

lt : less than
gt : greater than

;)


autre solution, utiliser une portion CDATA qui évite d'avoir à échapper les caractères spéciaux XML.

Dans ton cas ça donnerait ça :

Code:

---

<string><![CDATA[t.technicien Is Not NULL And t.technicien <> '']]></string>

---

Il y a peut-être une contrainte que j'ai pas vu, un besoin caché, mais quand même : utiliser XML pour ça, c'est un marteau-pilon pour tuer une mouche. Pourquoi ne pas faire simple ? Ce sera plus rapide à faire tout de suite, et plus maintenable à long terme.

Tout ce que tu veux, c'est une clé => une requête : prend un fichier properties, ça se lit en une seule ligne avec un java.util.ResourceBundle. Pour tes compléments optionnels : tu adoptes une convention, par exemple "clé" pour la requête et "clé.1", "clé.2", etc. pour les compléments. Tu fais une petite classe wrapper autour pour stocker ton bundle, avec une méthode utilitaire pour récupérer une liste des compléments pour une clé donnée, et tu es parti.

Ca t'aura pris une heure, et si à l'avenir le besoin devient plus complexe, tu n'auras que l'intérieur de ton wrapper à reprendre. Par contre, effectivement, c'est moins amusant que de jouer avec XPath ;)

justement, il a une clé, plusieurs requêtes ;-) donc le properties ne va pas sans faire les ".1" et ".2" qui sont bien chiants à implémenter (comparer à un parsing XML qui le fait tout seul).

Ca ne reste que mon avis. :aie:

Merci pour vos réponses :)

Boojum, ce que tu me conseilles parait être une solution aussi :D Je n'ai jamais manipulé de fichier properties, mais je veillerai à m'y intéresser :P
Je dis ça car j'ai réussi à mettre en place mon XPath et mon JDOM, et ça a l'air de fonctionner : je recherche bien mes requêtes, le parsing se fait correctement, et les parties sont retournées en un éclair grâce au XPath :mrgreen:

fxrobin j'ai bien pris note et j'ai placé des CDATA, je me prends moins la tête à échapper les caractères un par un :aie:

Bref, la migration bdd>XML suit son cours donc je vous tient au courant :ccool:
Et si jamais je vois que ça coince j’essaierai avec un properties et wrapper (faudra déjà que je m'exerce :aie: )

Citation:

---

Envoyé par fxrobin

justement, il a une clé, plusieurs requêtes ;-) donc le properties ne va pas sans faire les ".1" et ".2" qui sont bien chiants à implémenter (comparer à un parsing XML qui le fait tout seul).

---

Uh ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

private ResourceBundle bundle = ResourceBundle.getBundle("queries");   public List<String> getComplements(String key) { int i = 1; List<String> result = new ArrayList<String>(); while (bundle.containsKey(key + "." + i)) { result.add(bundle.getString(key + "." + i)); i = i + 1; } return result; }

---

10 minutes, 10 lignes :mrgreen: Désolé, j'ai juste une dent contre le XML utilisé à tout bout de champ, j'en ai trop vu...

Citation:

---

Envoyé par Boojum

Uh ?
10 minutes, 10 lignes :mrgreen: Désolé, j'ai juste une dent contre le XML utilisé à tout bout de champ, j'en ai trop vu...

---

Code:

---

1 2 3 4

Document doc = sxb.build(is); XPath xpa = XPath.newInstance("//requete[name='truc']"); String requete = ((Element) xpa.selectSingleNode(doc.getRootElement())).getText();

---

2 minutes, 3 lignes :mrgreen:
j'suis 5 fois plus rapide :mouarf: I love XML :aie:


mais j'aime bien aussi les properties, je trouve juste que c'est pas forcément adapté à son besoin ;)

Bon alors j'ai réussi à tout passe par le XML, ça fonctionne :ccool: :mrgreen:
Quand je profile à nouveau l'appli, les requêtes qui étaient avant utilisées pour la récupération des requêtes ont totalement disparues :D

Par contre pas de différence flagrante au niveau des temps de chargements à l'utilisation, mais bon au moins l'appli est allégée :mrgreen:

:ccool:

J'ai oublié : grand merci pour vos aides :ccool: