PreparedStatement et nombre indéfini d'arguments

Bonjour/Bonsoir à tous,

je vous explique la situation :

mon application Web de E-Commerce met à disposition de l'utilisateur un formulaire de recherche afin qu'il puisse retrouver les produits qui l'intéressent...
tous les produits sont stockés en Base de Données (IBM DB2)...

la recherche est effectuée sur les champs name et description de la table ITEMS (il suffit que le mot clé soit dans l'un ou l'autre de ces champs)...

si la requête était traitée dans son ensemble (sans découpage), la requête préparée aurait la forme suivante :

Code:

---

SELECT * FROM AR.ITEMS WHERE LOWER(name) LIKE %?% OR LOWER(description) LIKE %?%

---

mais évidemment, la saisie de l'utilisateur est "tokenizée", et c'est à partir de là que tout se complique... je dois utiliser les preparedStatement pour effectuer la recherche (et pour parer à tout risque d'injection SQL) et retourner une liste d'objets Items... or, la saisie de l'utilisateur peut très bien comprendre 20 tokens comme un seul...

exécuter n requêtes pour n keywords ne me paraît pas être une bonne solution...


savez-vous s'il est possible de n'utiliser qu'une seule requête préparée pour traiter la requête utilisateur et retourner la liste des résultats ?
et si ce n'est pas le cas, quelle est la meilleure solution à ce problème ?


Merci d'avance,
Rolf

Bonjour,

Je ne suis pas très sûr d'avoir compris ton problème, mais tu peux par exemple construire une chaîne de caractère "condition" qui aurait comme forme : %?%%?

Pour cela, il faut mettre autant de '%?' que de tokens. Ensuite tu construis ta requête :

Code:

---

"select * from items where description like "+condition

---

Et enfin tu boucles sur les tokens en appliquant setXxx(i,token)

J'espère que ça répond à ta question ;)

@+

merci de votre rapidité !

ça peut y répondre effectivement...
néanmoins, j'ai un petit doute...

dans mon cas, l'utilisation de l'opérateur IN n'est pas adaptée, c'est pourquoi j'utilise plutôt LIKE...

or, si je veux construire ma requête dynamiquement, je ne vois pas trop comment concaténer mes paramètres...

le bout de requête suivant est-il syntaxiquement correct ??

Code:

---

[...] WHERE nom_champ LIKE "%?%","%?%","%?%"

---

ou dois-je construire la requête de la sorte ?

Code:

---

[...] WHERE nom_champ LIKE "%?%" OR nom_champ LIKE "%?%" OR nom_champ LIKE "%?%"

---

si seulement la deuxième formule est correcte, je ne vois pas comment je peux construire ma requête préparée dynamiquement....

Pour chaque token tu concatène la chaîne '%?', et tu ajoute un % à la fin
Ainsi ta requête aura à peu prêt cette tête :

Code:

---

[...] WHERE nom_champ LIKE "%?%?%?%?%"

---

pour quatre tokens

@+

merci encore de la rapidité de la réponse...

toutefois, je ne suis pas sûr d'avoir compris...
si j'utilise %toto%titi%tata%, seuls les items qui contiennent ds leur nom/description les TROIS tokens seront retournés, non ?

or pour qu'un item soit retourné, il suffit qu'il n'ait qu'un des trois keywords dans son nom/sa description...

bref, ce n'est pas encore très clair...

imaginons que j'ai trois items stockés en BD (name | description) :

1. voiture rouge | jolie voiture neuve pas chère du tout
2. chaussure bleue | magnifique chaussure d'occasion qui sent encore le moisi
3. tarte à la crème | à consommer avant le 24/12/1906

quels items seront retournés si l'utilisateur saisit "tarte moisi 1906" ??

Avec mon exemple, aucun item n'est retourné
Je comprends mieux maintenant ton problème ! tu peux néanmoins appliquer le même principe mais en concaténant la chaîne "nom_champ LIKE "%?%"" pour chaque token :

Code:

---

1 2 3 4 5 6 7 8 9

String requete = "select * from items where"; for(int i=0; i< listeTokens.size(); i++){ if(i==0){ requete = requete + " nom_champ LIKE '%?%'"; }else{ requete = requete + " OR nom_champ LIKE '%?%'"; } }

---

Puis tu reboucles à nouveau pour affecter les tokens au prepared statement

Remarque : ce code peut être largement optimisé avec des StringBuilder,...

@+

merci beaucoup !
je n'ai plus qu'à appliquer tout ça !

a priori, je vois pas d'autres solutions possibles de toutes façons...