Discussion :

[Papy214]

Bonjour à tou(te)s,

Je poste ici parce que la langage utilisé est Delphi tout en étant bien conscient que c'"est plus généraliste que ça.

En parcourant le code source d'un projet d'un autre développeur, j'ai trouvé un formulaire permettant de composer une recherche détaillée d'élément(s) sur une base de données SQL Server.
La façon d'arriver à la requête finale donnant la solution me semble vraiment très complexe, basée sur une foultitude de "if" imbriqués pour ajouter divers champs, tables, condition, etc.

Et là, je me suis dit que ça ferait un sujet intéressant à développer ici en ce beau mois d'août.

Donc, à partir d'un formulaire comprenant des champs de saisie, des listes de choix, des cases à cocher, etc. quelle méthode employez-vous (ou emploieriez-vous) ?

• Le système décrit ci-dessus avec plein de if et de case difficilement compréhensibles ?
• Des requêtes toutes préparées pour chaque cas possible ?
• Une librairie style hibernate pour générer des requêtes plus facilement ?
• Un système en plusieurs étapes genre assistant de filtres enchaînés ?
• Autre ?

Tous les avis m'intéressent même les plus farfelus

[ShaiLeTroll]

J'ai voté

Une de "if" et de "case" difficilement compréhensibles
ET
Un maximum de requêtes préparées à l'avance

Oui, c'est contradictoire mais cela dépend de la complexité du moteur de recherche et des pratiques existantes dans la société qui m'employait.
Si tu as une DB mal structurée, comme c'est souvent d'ailleurs, on peut s'arracher les cheveux !

Tout dépend à qui s'adresse le module de recherche ?
Si il faut connaitre la structure de la DB pour faire sa recherche, cela limite évidemment la cible ...

J'ai utilisé Une de "if" et de "case" difficilement compréhensibles
Plus des boucles qu'autre chose.
Chaque champ était identifié (une énumération) et ensuite un gros tableau déclaratif contenant, le nom du champ, la table, l'arbre des jointures nécessaires, le FieldType, l'opérateur ...
Et cela ne concernait que la partie Where
En plus, il y avait des calculs à effectuer pour avoir l'affichage souhaiter par les utilisateurs (quelques options configurables)

Finalement, n'était-ce pas "•Un système en plusieurs étapes genre assistant de filtres enchaînés ?"
Je n'ai pas bien compris sur le coup cette proposition, en réfléchissant un peu plus, le générateur de SQL était proche de cela !

Pour l'utilisateur, c'était totalement transparent, il renseignait un champ, lançait sa recherche et avait son résultat
Derrière, si le module a du faire 10 jointures pour appliquer le critère et obtenir les données souhaitées, ce n'était pas son problème, bien heureusement !


j'ai aussi Un maximum de requêtes préparées à l'avance
Parfois une seule requete suffit du genre

Code sql :

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

1
2
3
4
5
 
WHERE  (:param1 IS NULL or :param1 = champ1)
   AND (:param2 IS NULL or :param2 = champ2)
   AND (:param3 IS NULL or :param3 = champ3)
   AND ...

Si le paramètre est null, ça prend tout, si celui contient une valeur, c'est un critère de recherche
Certains optimiseur SQL de SGBD n'apprécie pas ce genre de syntaxe et faut construire la requête (on en revient au if)


Enfin, j'ai aussi maintenu des programmes qui contenait leur propre générateur de requête, c'est le XML qui contenait le nom du champ, la table, l'arbre des jointures nécessaires, le FieldType, l'opérateur ...
Certains très basiques où il fallait le faire à la main
pas de soucis, on proposait trois formations payantes à la création de stat (débutant, confirmé, expert)
Au final, le client était dépassé par la masse de travail et chaque stat, chaque export c'était une tache facturée ... une source de revenue pour la société

D'autres, un environnement graphique et finalement rares sont les utilisateurs se mouillaient vraiment et c'était encore plus rentable pour la société puisque peu de temps de travail était facturé bien salé !


Il y a un an, ou je travaille, j'ai fait un mini moteur de recherche et j'ai appliqué
Un maximum de requêtes préparées à l'avance
4 Onglets, chaque onglet correspond à une requête prédéfinie, chaque onglet contient un champ de saisie qui cible un champ précis
Au fur et à mesure, on m'a demandé des critères alternatifs, d'appliquer le même criètre mais à d'autres champs
et maintenant, c'est des bouts de SQL concaténés par des if ...
Mince, retour au 1er cas ! Pas de Chance !

Pour illustrer le dernier cas, il est assez court mais il y a déjà un tas de if ... voir fichiers joints

[e-ric]

Salut

Pas d'avis en particulier,

Des requêtes toutes préparées pour chaque cas possible ?

La combinatoire risque d'avoir ta peau ... Les instructions d'identification de la requête à appliquer seront peut-être tout aussi compliquées.
Ou alors il faut limiter drastiquement leur nombre.

Un système en plusieurs étapes genre assistant de filtres enchaînés ?

Cela peut permettre aussi de construire progressivement la requête et de répartir la complexité du code en plusieurs étapes.

Je me souviens que dans un projet avec du Cobol+DB2 (que du SQL statique) en serveur et du Delphi en client, nous avions dû faire une croix sur les requêtes dynamiques. Dans ce cas, seules des requêtes pré-définies (et en nombre limité) restait faisable.

Cdlt

[SergioMaster]

Bonjour,

Rien n'est simple surtout lorsqu'il y aura jointures ou CTE !
Aucun des composants/ logiciel déjà existant ne m'a vraiment satisfait, le "query by example" visuel que j'avais pu proposer au tout début de la rédaction de mes applications (+15 ans déjà) n'a jamais été utilisé par les utilisateurs ! (si mes souvenirs sont bons j'utilisais MKQueryBuilder, du coup je ne le propose même plus)
une bibliothèque des requêtes courantes à été mise en place et tous sont largement satisfait, il m'arrive d'avoir à en rajouter une ponctuellement mais pas plus de 2 fois par an grand max !

du coup je ne sais même pas quoi voter ! autre ..... je penche plutôt pour un maximum de requêtes préparées (et expliquées) et un programme qui sélectionne la requête, étudie les paramètres pour en faire la demande (si en plus les composants Query permet les macros c'est encore mieux)

[anapurna]

salut

si ta cible est l'utilisateur final il est préférable de créer un écran avec des case à cocher , des bouton radio et ou des Combo-box voir même des liste de case a cocher pour déterminer les différents éléments table,filtre, regroupement, ordre d'apparition .
cela d'une part évite les requête qui parte en vrille et bloque ton système ^^
d'autre part tu maîtrise complètement le processus de création de ta requête
si a l'inverse cela s'applique a un développeur un simple mémo attaché a une base doit suffire
plus sérieusement j'utilise souvent une outils perso lanceur de requête, me permettant de voir la structure des tables, des procédure stocké et des view
le tout avec la possibilité d'exporter le résultat dans Excel

[GoustiFruit]

Jusqu'ici j'ai pu m'en sortir avec quelques if imbriqués, ouf !

Je suppose que c'est dans ce genre de situation qu'une unité comme GpSQLBuilder de "gabr" montrerait toute son utilité !?

[Papy214]

Merci de vos retours d'expérience !

J'aurai du préciser que dans le cas sur lequel je suis "tombé" concerne des utilisateurs lambda (sans dénigrement aucun).
Proposer un memo pour composer une requête n'est pas du tout adapté

Je déduis de tout ça qu'il n'y a pas de solution miracle et qu'au final le plus judicieux est de mâcher le travail au maximum à l'utilisateur final.

Dans une application , j'utilise les grille de la suite SMComponents qui est pas mal et à laquelle on peut lier un composants de recherche qui permet de faire des requêtes simples.
Et en fait, personne ne l'utilise vraiment.

Le composant GpSQLBuilder est intéressant. Il me rappelle bigrement NHibernate que j'avais utilisé il y a longtemps dans une application en C#.
Je vais le regarder de plus près.

Et je retiens aussi l'idée de Shai sur le paramètre potentiellement null qui peut simplifier pas mal de choses dans la construction de la query. Je ne suis pas sûr que ça me serait venu à l'idée