Gestion d'une recherche avancée

Bonjour,

Je travaille actuellement sur un module de recherche avancée sur des données présente dans ma base de données et je m'arrache les cheveux.

Le principe est le suivant :

L'utilisateur dispose d'un outil lui proposant de manière shematique la chose suivante :

:arrow: 1> selection de la table de recherche
:arrow: 2>selection du champ de recherche
:arrow: 3>selection de l'operateur de comparaison
:arrow: 4>selection de la valeur

cette série d'action est repetable N fois par l'utilisateur afin de lui permettre d'affiner sa requete. Au bout de la 2eme fois l'utilisateur doit passer par une etape 5:

5>selection d'un opérateur logique (ET ou OU)


Mes contraintes :

- l'utilisateur doit construire sa requete de facon intuitive (ce ne sont pas des dev)
- je dois stocker cette recherche dans la base de données.


Mes problèmes sont les suivants :

:?: Comment definir les blocs de données concerné pars les operateurs logiques (et/ou)
:?: Comment gérer les jointures


J'avais etabli un premier modéle mais j'ai vite vu qu'il etait trop limité et ne permettait pas la liberté que je souhaite laissé aux utilisateurs.

Avez vous des pistes de réflexion car là je sèche...



http://loctar.free.fr/test/modele4.GIF



Merci pour votre aide

Si je comprend bien, tu désires permettre à l'utilisateur de construire une requete de maniere intuitive sans qu'il ait à connaitre la syntaxe SQL ...

C'est pas gagné... une première solution serait de leur fournir ACCESS :D ... mais bon treve de "plaisanterie"

Pour les jointures, il suffit à mon avis de le brider danjs le choix des tables selon les jointures faisables... si tu veux lui permettre de choisir nimporte quelle table, ca releve d'un algorithme du plus court chemin (DIJKSTRA) que l'on peut trouver sur internet ou bien en demandant sur le forum "Algorithmes" :wink:

Pour les bloc OU/ET tu n'as pas d'autre choix que de definir une priorité entr les deux.. soit tu demandes ca a l'utilisateur au debut, soit tu la fixes et le stipule lors de la construction ... en general, on met plutot une priorite sur le ET en SQL (plusieurs conditions de filtre et non pas l'union de conditions ... donc ma solution, si tu a un OU tu parentheses les deux blocs de chaque cote alors que tu ne fais rien avec un ET

Enfin une derniere chose me tracasse ... comment procede tu a la selection des champs à afficher ?

en gros si l'utilisateur entre ceci :

Code:

---

A et B ou C , je traduis ceci de la manière suivante : (A et B) ou C

---

ou encore :

Code:

---

A et B ou C ou D et E donnerait : (A et B) ou ((C) ou (D et E))

---

Pour les champs à afficher, je vais proposer une grande liste correspondant à l'ensemble des champs appartenant au tables requêtées (c'est francais comme mot ca :wink: ? ) et l'utilisateur pourra choisir les champs à afficher.

:cry: mais je viens de tomber sur un soucis :

A et B ou C et D ou E


comment traduire cette requete ?

1:?: (A et B ) ou ((C et D ) ou E )
2:?: ((A et B ) ou (C et D)) ou E


Je pencherai pour la première interprétation...

Moi je séparerai 2 choses dans ton cas :
1- La définition par l'utilisateur d'une requête complexe
2- Le stockage de cette requête

Pour le 1, je l'aiderai via des listes déroulantes pour le choix de tables / vues et colonnes
Pour le 2, je ne me casserai pas la tête à stocker la règle de manière "structurée" mais je stockerai simplement la règle en lui donnant un nom (nom donné par l'utilisateur éventuellement) et je stockerai le code SQL complet de la requête.

Pour exploiter la requête par la suite, je procéderai pas introspection éventuelle du "ResultSet"

OUi tu as raison pour le stockage des requetes toutefois, dans mon cas le problème n'etait pas tant de les stocker mais de les construires :)

Et dans ce meme cas puisque j'ai une structure qui me permet de les stocker, pourquoi ne pas en profiter.

donc apparemment, tu met le OU en prioritaire logique et tu donc donc les parentheses sur les ET ... c'est peut etre moi qui aurait du mettre un exemple ... mais ce que je voulais dire c'etait plutot l'inverse ... :

A et B ou C => A et (B ou C)

car en general, un utilisateur aura plus tendance à vouloir les gens gagnant plus de 1000euro et dont le prenom est gilles ou henry plutot que les gilles qui gagnent 5000euros ou les henry ... tu vois ce que je veux dire ?

pour ton probleme ... ca restera "problematique" quel que soit ton choix car l'utilisateur devra, dans les deux cas, formuler ses besoins selon tes choix ... la meilleure solution selon moi c'est de laisser l'utilisateur fixer ses priorités (il met lui mm les parentheses, pourquoi pas :) ...) et tu regardes juste si, syntaxiquement, ce qu'il a mis est juste ... mais bon, encore une fois ce sont des choix de programmation qui sont tiens ^^

Tu as entièrement raison , concernant le fait de laisse à l'utilisateur le chiox de fixer ses "bloc" conditionnels toutefois, etant donné que ces derniers sont des néophites et non aucune connaissance en SQL..

Je pense que si je les laisse fixer eux meme ces parametres ils vont se perdre très rapidement au bout de 3 ou 4 conditions...

(c'est d'ailleur pour ca que je traduis en francais littèral les requetes qu'ils mettent en place via les différentes listes déroulantes...)

Je ne pensais pas me mordre les doigts sur cette partie du dev...
(d'autant plus que j'etais content de mon modèle de données avant d'en voir les limites en developpant)

Sans avoir de connaissance en SQL ... n'ont il pas quand mm une once de logique en eux ? n'ont ils jamais fait de maths en mettant des parentheses la où ils veulent des priorités ? ... ce que je veux dire en fait c'est qu'il est toujours possible de parentheser les conditions en francais ... out le monde sait dire :

je veux :
qq1 qui gagne plus de 1000euros ET
(qq1 qui s'appelle pierre OU qq1 qui s'appelle henry)

ce n'est pas, je pense un probleme SQL mais un simple probleme logique :wink:

Essaie de vori si cette solution n'est vraiment pas jouable :razz: ... sinon c clair, il va suivre plusieurs problemes auxquels on en pense pas forcement :
1/ non comprehension de ton formalisme logique
2/ non reussite de reformulation de leur condition selon ton formalisme
3/ abandon de ta recherche si ils ne reussissent pas vite fait selon leur logique

chaque personne pense differemment si de ton cote tu preferes imbriqués des conditions, certains preferent les mettre a plat ... certains factoriseront, d'auteres developperont .... je pense que tu passeras plus de tps en dvlpt mais tu y gagneras en appreciation du resultat :wink:

histoire de participer, je pense comme BizuR.
Si les gens veulent faire des combinaisons complexes de critères c'est qu'ils en ont besoin et donc qu'ils comprennent ce qu'ils font; ce n'est donc pas un pb de SQL.
S'ils ne veulent pas de trucs complexes, ils ne le feront pas, tout simplement.
Il y a qq années, j'avais fait un truc comme cela pour une application financière et ce que j'avais proposé, c'est :
1- Ecriture libre de la formule, avec vérification syntaxique ensuite
2- et création assistée via la possibilité d'utiliser des opérateurs uniares ou binaires + l'utilisation de parenthèses. Tout cela via des menu de type "ajouter un ...." et écriture "temps réel" de la formule résultante.

Pour faire tout cela, il te "suffit" de décrire ta formule via des objets Java colonne, donnée et opérateurs (unaire et/ou binaire). Pour parser une formule toute faite, tu peux utiliser JavaCC pour générer un parser de formules.
C'est peut être un peu lourd, je ne sais pas, mais une fois mis en place, ton imagination n'aura plus de limite

Bon ca y est j'ai mis en place mon systeme.

Dans le cas d'une requete multiple, je propose, pour chaque definition de critères de recherche, à l'utilisateur s'il souhaite defnir ou non un ensemble de critere.

A la suite de cette requete, l'utilisateur de la possibilité de refermer 0,1 ou n ensembles précédemment ouverts.

J'ai présenté cette solution à mon entourage et elle semble viable...

J'ai une fois développé ce genre de truc. J'avais réglé le problème de ce genre de condition:

Code:

---

1 2	((A ou B) et (C ou D) et (E ou F)) et (G ou H)

---

(par exemple), en appliquant le Design Pattern "Composite" et en considérant qu'une condition pouvait être un ensemble de condition (parenthèse) et ainsi de suite...

oui, ce pattern est tout à fait adapté à la modélisation de formules.
Dans le cas d'opérateurs logiques, on a une sorte d'opérateur binaire dont le résultat est vrai ou faux